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

2010-05-03 Thread 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 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 . but your depth texture mode was
alpha, you'll get a nice ....

 
 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


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

2010-05-03 Thread Brian Paul

Jose Fonseca 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:


Correct.



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. 


Mmm, I don't think so.

Regardless of the original user texture component ordering and 
regardless of the actually hardware texture format, when the shader 
calls texture2D(sampler, coord), for example, it _always_ returns a 
vector of (R, G, B, A) in that order.  Similarly for ARB_vp/fp and 
fixed-function texture sampling.


We'd have a miserable time writing shaders if we texture2D(sampler, 
coord) returned different component orderings depending on the actual 
texture format (which could vary from one system to another).


An extenstion like GL_EXT_bgra is used to describe the incoming/user 
texture data to glTexImage2D, nothing about the internal/actual 
texture layout.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2010-05-03 Thread Brian Paul

Dave Airlie wrote:

In looking at adding EXT_texture_swizzle I'm a bit confused about what
exactly should happen with BGRA textures, as on r300 we use the
texture swizzling to do BGRA, so we would have some interaction at
that point.

To make sure we test for this I've made the following enhancments to
the glean test (in piglit tree - but I'll resubmit against glean tree
if correct).

Can someone with a clue make sure this is a sane test, it passes
against swrast..


The patch is sane.  You're basically just defining the user texture 
either in RGBA vs. BGRA order in the two cases.  This has no bearing 
on the internal/actual format of the texture or the results of 
sampling from the texture.


However, I suggest:

1. use a better name for the 'format_pick' variable
2. add a comment for that parameter.
3. it's used as a boolean, so s/int/bool/
4. fix up the indentation to match the rest of the file.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2010-05-03 Thread José Fonseca
On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote:
 Jose Fonseca 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:
 
 Correct.
 
 
  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. 
 
 Mmm, I don't think so.
 
 Regardless of the original user texture component ordering and 
 regardless of the actually hardware texture format, when the shader 
 calls texture2D(sampler, coord), for example, it _always_ returns a 
 vector of (R, G, B, A) in that order.  Similarly for ARB_vp/fp and 
 fixed-function texture sampling.

 We'd have a miserable time writing shaders if we texture2D(sampler, 
 coord) returned different component orderings depending on the actual 
 texture format (which could vary from one system to another).

Actually, this is what I meant, but I see now I explained miserably!
(@_@)

What I meant is that if the user specifies a BGRA texture with the
_bytes_:

  X Y Z W

and we specify the TEXTURE_SWIZZLEs as (R, G, B, A) then we'd obtain

  W Z W X.

in the shader (normalized by 1/255).

What I mean is that the format swizzles have to be composed with the
shader swizzles.

 An extenstion like GL_EXT_bgra is used to describe the incoming/user 
 texture data to glTexImage2D, nothing about the internal/actual 
 texture layout.

Yes.

Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2010-05-03 Thread Brian Paul

Dave Airlie wrote:

On Sat, May 1, 2010 at 6:47 PM, Dave Airlie airl...@gmail.com wrote:

In looking at adding EXT_texture_swizzle I'm a bit confused about what
exactly should happen with BGRA textures, as on r300 we use the
texture swizzling to do BGRA, so we would have some interaction at
that point.

To make sure we test for this I've made the following enhancments to
the glean test (in piglit tree - but I'll resubmit against glean tree
if correct).

Can someone with a clue make sure this is a sane test, it passes
against swrast..



Hmm on a second look inside mesa, it appears it never stores textures
internally as BGRA, it always does a swizzle translate on the way in,
so this test won't help me there, I'll have to think up something a
bit more intricate to test this stuff.



There's often texture swizzling involved in converting the 
user-provided image (GL_RGBA vs. GL_BGRA vs. GL_ABGR_EXT, etc) to the 
actual hardware texture format (MESA_FORMAT_RGBA, 
MESA_FORMAT_ARGB_REV, etc).


BTW, people concerned with glTexImage() performance should do some 
experimentation with different source formats/types to find one that 
(hopefully) avoids swizzling and can just be memcpy'd.


For swrast, Mesa prefers the MESA_FORMAT_RGBA format for slightly 
faster software rendering on some paths.  If you want to force a 
different internal format for testing with swrast, just modify the 
_mesa_choose_tex_format() function in texformat.c.  There's similar 
code for gallium in st_ChooseTextureFormat().


There's a glean test (packedPixels??) that exercises all the different 
glTexImage() format/type combinations if you're looking for something 
that will hit different texture formats.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2010-05-03 Thread José Fonseca
On Mon, 2010-05-03 at 10:29 -0700, José Fonseca wrote:
 On Mon, 2010-05-03 at 09:44 -0700, Brian Paul wrote:
  Jose Fonseca 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:
  
  Correct.
  
  
   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. 
  
  Mmm, I don't think so.
  
  Regardless of the original user texture component ordering and 
  regardless of the actually hardware texture format, when the shader 
  calls texture2D(sampler, coord), for example, it _always_ returns a 
  vector of (R, G, B, A) in that order.  Similarly for ARB_vp/fp and 
  fixed-function texture sampling.
 
  We'd have a miserable time writing shaders if we texture2D(sampler, 
  coord) returned different component orderings depending on the actual 
  texture format (which could vary from one system to another).
 
 Actually, this is what I meant, but I see now I explained miserably!
 (@_@)
 
 What I meant is that if the user specifies a BGRA texture with the
 _bytes_:
 
   X Y Z W
 
 and we specify the TEXTURE_SWIZZLEs as (R, G, B, A) then we'd obtain
 
   W Z W X.

I must be getting dyslexic. Z Y X W should be the answer. 

 in the shader (normalized by 1/255).
 
 What I mean is that the format swizzles have to be composed with the
 shader swizzles.
 
  An extenstion like GL_EXT_bgra is used to describe the incoming/user 
  texture data to glTexImage2D, nothing about the internal/actual 
  texture layout.
 
 Yes.
 
 Jose
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2010-05-02 Thread Dave Airlie
On Sat, May 1, 2010 at 6:47 PM, Dave Airlie airl...@gmail.com wrote:
 In looking at adding EXT_texture_swizzle I'm a bit confused about what
 exactly should happen with BGRA textures, as on r300 we use the
 texture swizzling to do BGRA, so we would have some interaction at
 that point.

 To make sure we test for this I've made the following enhancments to
 the glean test (in piglit tree - but I'll resubmit against glean tree
 if correct).

 Can someone with a clue make sure this is a sane test, it passes
 against swrast..


Hmm on a second look inside mesa, it appears it never stores textures
internally as BGRA, it always does a swizzle translate on the way in,
so this test won't help me there, I'll have to think up something a
bit more intricate to test this stuff.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2010-05-02 Thread Jose Fonseca
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.

Jose

From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org 
[mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Dave 
Airlie [airl...@gmail.com]
Sent: Sunday, May 02, 2010 10:01
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] EXT_tetxure_swizzle and BGRA textures : glean test  
enhancement

On Sat, May 1, 2010 at 6:47 PM, Dave Airlie airl...@gmail.com wrote:
 In looking at adding EXT_texture_swizzle I'm a bit confused about what
 exactly should happen with BGRA textures, as on r300 we use the
 texture swizzling to do BGRA, so we would have some interaction at
 that point.

 To make sure we test for this I've made the following enhancments to
 the glean test (in piglit tree - but I'll resubmit against glean tree
 if correct).

 Can someone with a clue make sure this is a sane test, it passes
 against swrast..


Hmm on a second look inside mesa, it appears it never stores textures
internally as BGRA, it always does a swizzle translate on the way in,
so this test won't help me there, I'll have to think up something a
bit more intricate to test this stuff.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev