On 02.05.2010 13:08, José Fonseca wrote: > On Sun, 2010-05-02 at 02:36 -0700, Dave Airlie wrote: >> On Sun, May 2, 2010 at 7:30 PM, Jose Fonseca <jfons...@vmware.com> >> wrote: >>> I read the extension and it is not crystal clear, but it seems to >>> imply the swizzles are orthogonal to the format, and applied as >>> the very last step before being used in a shader. That is, the >>> semantics are the same of adding a swizzle instruction after a >>> TEX opcode, regardless of the format. At least this is my >>> interpretation of >>> >>> The values of the texture parameters TEXTURE_SWIZZLE_R_EXT, >>> TEXTURE_SWIZZLE_G_EXT, TEXTURE_SWIZZLE_B_EXT, and >>> TEXTURE_SWIZZLE_A_EXT, are applied after the swizzling described >>> in Table 3.20 (p. 186). The swizzle parameter >>> TEXTURE_SWIZZLE_R_EXT affects the first component of Cs as: >>> >>> BGRA extension does not specify additions to the 3.20 table >>> though (it's against spec 1.1) so this is why the guess work. >>> >>> So my expectaction is that swizzling a BGRA with a .rgba swizzle >>> will get bgra. >>> >>> It is also interesting the mention that the swizzle happens after >>> texture compare mode. > > Actually, I mistyped, it is not texture compare mode, just depth > texture mode. Yeah, this is all a bit confusing, but the depth texture comparison, if enabled, always uses the depth value from the texture, as you'd expect. This value then gets assigned to rgba/rgb/a depending on depth texture mode. So the texture swizzle happens after that - of course that means if you have specified a swizzle of .rrrr but your depth texture mode was alpha, you'll get a nice .0000...
> >> That is my interpretation as well, so in the r300 hw for example we >> use the texture swizzle to implement bgra vs rgba formats, I'd >> need to combine that with the incoming GL swizzle from the >> extension, but I'd really like to have some sort of test case to >> demonstrate it as I'm really not sure how ugly the combine swizzles >> function might end up. But it looks as if I need to write a direct >> to gallium test case to make sure I'm actually using things, mesa >> seems to block my attempts, though maybe with something like a PBO >> I can make mesa do it. > > I see now. > > It's probably worth to fix Mesa to memcpy user data unmodified as > much as possible. grepping for GL_BGRA and PIPE_FORMAT_B8G8R8A8 in > mesa shows some inconsistencies. Even for PBOs we say that > PIPE_FORMAT_B8G8R8A8 is GL_RGBA and not GL_BGRA. > > A good way to go about this is centralize Gallium <-> GL and Gallium > <-> Mesa format information in a big table. It means whenever a new > format is added, there are a few places to modify. > > Anwyay this cleanup is not urgent, and is likely to cause > regressions. FWIW, there's not only interaction with textures with different ordering (like bgra) but also those which are defined as rgb1 for instance. If you specify a swizzle of .aarr for instance, of course you'll get .11rr effectively. Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
