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

[Stefan Dösinger]

> It's not about gaining stuff, it's about creating an interface that
> makes sense, even in the long term. If I look at the shader_color_conv
> enum, I might be able to guess what each element is supposed to do,
> but I don't really know until I look at what formats it's used with,
> and how GLSL and ARB implement that specific conversion. That's bad if
> I would want to implement a shader backend, but it's also bad if I
> want to add support for a new format that needs this kind of
> conversion. I would need to look through the list and implementation
> to see if there's a conversion that does what I want, and if there
> isn't, add an element to the list and implement it in all backends.
> Describing the operation that needs to be performed on each component
> on the other hand would allow both the implementation and the code
> using it to be mostly generic.
I agree in theory, but I doubt that this works in practise. To understand what a more fine-grained interface does you still have to read the code or the docs(e.g. the EXT_texture_swizzle spec, although we can't use that as-is).

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.

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.

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)

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)

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.