[Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test enhancement

[José Fonseca]

On Sun, 2010-05-02 at 02:36 -0700, Dave Airlie wrote:
> On Sun, May 2, 2010 at 7:30 PM, Jose Fonseca <jfonseca at 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. 

> 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.

Jose