[Mesa-dev] [RFC] [BRANCH] Floating point textures and rendering for Mesa, softpipe and llvmpipe

[José Fonseca]

On Fri, 2010-08-27 at 05:49 -0700, Luca Barbieri wrote:
> I created a new branch called "floating" which includes an apparently
> successful attempt at full support of floating-point textures and
> render targets.
> 
> I believe it is fundamentally correct, but should be considered a
> prototype and almost surely contains some oversights.
> 
> Specifically, the following is included:
[...]
> 10. llvmpipe is converted to use float tiles instead of uint8_t tiles
> 11. For llvmpipe, blending is reworked to work with both fixed and
> floating point target, and fragment clamping is properly supported
[...]
> * LLVMpipe
> 
> LLVMpipe has the fundamental problem that it uses an intermediate
> tiled format with byte components for all surface formats.
> 
> To resolve this, this patchset switches it to use float components for
> all formats.
> Note that this is still a bad choice, and the same format of the
> surface should be used if natively supported by the CPU, or otherwise
> a suitable more precise format should be chosen.
> 
> After this drastic change, the modifications imitate the changes to softpipe.
> 
> Note that this code must not be merged as is, since using floats will
> likely degrade performance and memory usage unacceptably.
> The tile code should instead be rewritten to support all possible tile formats.
> 
> Also, while this patch blends in floating point, it should blend in
> the destination format, since that gets correct clamping for free and
> is faster, since the destination format is often smaller.
> 
> * Unsolved stuff
[...]
> 
> * Merging this branch
> 
> To merge this, the following would be necessary:
[...]
> 4. Rewrite the tiling code in llvmpipe to support arbitrary formats

Hi Luca,

It's an impressive amount of work you did here. I'll comment only on the
llvmpipe of the changes for now.

First, thanks for going the extra length of updating llvmpipe.

Admittedly, always using a floating point is not ideal. A better
solution would be to choose a swizzled data type (unorm8, fixed point,
float, etc) that matched the color buffer format.

But we've been seeing some results which point that the whole color
buffer swizzling idea might be overrated: it increases memory bandwidth
usage substantially, and for many shaders where derivatives aren't
necessary or can be determined from inputs there's no need to process
2x2 quads of pixels or even computations in SoA. That is, we might end
up eliminating swizzling from llvmpipe altogether in the medium term.

So instead of going through a lot of work to support multiple swizzled
types I'd prefer to keep the current simplistic (always 8bit unorm)
swizzled type, and simply ignore errors in the clamping/precision loss
when rendering to formats with higher precision dynamic range. When we
add support to render directly to the unswizzled formats, support to
render these other types will come as well.

In summary, apart of your fragment clamping changes, I'd prefer to keep
the rest of llvmpipe unchanged (and innacurate) for the time being.

Jose