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

[Henri Verbeet]

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?

> Issue 2: The code that reads this information. If we want to generate efficient shader code that does the fixup in ideally one line of ARB asm we'll have to have lots of if checks for specific setups, and when we add a new fixup we have to add specialized code to each shader backend anyway. Keep in mind that we're not only reading RGBA components and 1.0 and 0.0 but also have the sign correction.
>
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.

> Issue 3: How do we compare two conversions efficiently? As long as we can pack it into a DWORD that works, but anything beyond that will get tricky(otherwise we could e.g. provide the color fixup as D3D ASM, that would avoid issue 2)
>
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.

> Issue 4: How do you describe YUV conversions? I don't want to move that into a different data structure because in the future we may want the blitting code to be able to handle non-YUV conversions too(e.g. R32F -> ARGB32F blits)
>
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.

> So in theory it sounds good, but I don't see what a nice implementation would look like. I'd be happy to be prooven wrong though.
>
I'd be happy to have a shot, should the implementation prove challenging.