[3/5] WineD3D: Fix D3DFMT_R32F, R16F, G16R16F, ... in the pixel shader

[Stefan Dösinger]

> 2008/11/27 Stefan Dösinger <stefan at codeweavers.com>:
> > Issue 1: I want to pack the color fixup information as tight as
> possible. A format like EXT_texture_swizzle needs more space for
> possible combinations we'll never use. My current enum needs 4 bits of
> storage.
> >
> Why do you think this is so important?
Because we have to verify the color fixup on 16+3 samplers each draw, and with d3d10 there will be many more(Of course in d3d10 we may be lucky and have all the formats natively in opengl without the need for shader conversion)
My automated performance tests show a small, but reproducible performance drop since my multiple pixel shader patches in some games. I have not yet checked why exactly, but I suspect its that the collection of all the stateblock data and the memcmp over the currently 72 byte ps_compile_args structure simply takes longer than the old CompileShader check. If we keep the color conversion information compact we can bring this structure down to 10 bytes.

> So you've got 4 swizzles, 1.0, 0.0 and a sign conversion. Should be
> easy in GLSL. ARB might be slightly harder, but I don't see how it can
> be as hard as you describe.
It's not really "hard", but I don't see how the whole code will look nicer in the end.
 
> If you really care deeply about memory usage, you can encode the
> entire conversion in 15 bits. If efficient decoding is also a
> requirement you'll probably need 16 bits.
That's 4 times as much as 4 bits...
I don't care about efficient decoding, but 15 bits isn't a helpful number so we'd have one spare bit anyway.
 
> YUV will be a special case either way, but note that if you go for the
> 16 bit encoding you'll have plenty of bits left to stuff some YUV
> ugliness in. Note that I'm not entirely convinced of the need for YUV
> conversion in shaders. Are there any actual applications that use any
> of the YUV formats with d3d8 or d3d9? There probably are for ddraw,
> but you don't have shaders there. D3d10 seems to have dropped the
> format completely. The fact that the YUV code currently breaks the
> d3d9 visual tests with FBO offscreen rendering mode and that you don't
> intend to fix that doesn't particularly help make me care.
Quicktime uses YUV formats in d3d9. It doesn't do any D3D geometry drawing with it(no windows driver supports that it seems), just blitting. I don't want to be able to do D3D drawing with YUV textures, but I'd like to be able to use the D3D shader conversion code with blitting should that become necessary.

And yes, YUV blitting is broken with FBOs, but that's a problem in the way the blitting codepath selection works, not the color conversion.