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

Henri Verbeet hverbeet at gmail.com
Thu Nov 27 13:43:06 CST 2008

2008/11/27 Stefan Dösinger <stefan at codeweavers.com>:
>> 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.
You'd still check the actual fixups, it just means that in most cases
you only have to check the bitmask, and for the cases where a fixup
*is* needed you only need to compare the samplers with a fixup. So if
you've got a single sampler with fixup you only need to check 16 bits,
if you've got two 32 bits, etc.

> 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)
Maybe, but you'll need to check if the conversion is supported either
way. Using one format or another for describing the conversion doesn't
change much there. YUV ugliness is relative, it basically comes down
to using the extra two values in each component to describe the type
of YUV format. I do think it is important to have sane interfaces,
even if they're mostly internal ones.

More information about the wine-devel mailing list