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

[Roland Scheidegger]

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