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

[Stefan Dösinger]

> It will likely be more efficient to only store and compare the
> samplers that need a fixup in the first place then. For most shaders
> you'll end up only checking a bitmask against zero in that case. Note
> that with a 16bit encoding you'd still cut the 64 bytes the array
> currently uses in half, in which case the structure would easily fit
> into a typical cacheline, if that's even the issue.
This looks like a nice idea. I don't know how we would catch a case where e.g. a sampler switches between two different formats that need conversion.

To get back to the original discussion though, I don't think we gain anything in terms of code readability(special case checking in arb), and if we need some YUV uglyness the interface doesn't look prettier. The other problem is that not all shader backends can do all the conversions, so we get problems with the shader / fragment pipeline implementation's is-this-conversion-supported callback(needs special case checking too).
(e.g. in atifs the sign fixup is supported and free, but other fixups may need up to 4 instructions per texture read, which is 1/4th of the shader already. I don't know what that would look like in nvts, but we currently don't need any color fixups there, so we probably never will)