2008/11/27 Stefan Dösinger <[EMAIL PROTECTED]>: > 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.
