Re: [Mesa3d-dev] Gallium format swizzles (Was: util: fix swizzles in the format table for 8-bits-per-channel formats)

[José F. <jfo...@vm...>]

On Tue, 2010-02-23 at 09:20 -0800, José Fonseca wrote:
> On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
> > On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
> > > Hi José,
> > > 
> > > the attached patch fixes incorrect swizzles in u_format.csv. There are
> > > basically just 2 drivers which depend on the swizzles in this table:
> > > llvmpipe and r300g. Since r300g started supporting pretty much every
> > > texture format except SCALED ones, a few regressions have showed up.
> > > This patch resolves all issues I had, especially with the SRGB formats
> > > but I decided to clean it up all. git log:
> > > 
> > >     util: fix swizzles in the format table for 8-bits-per-channel
> > > formats
> > >     
> > >     The 8-bits-per-channel formats having the same channel order had
> > > completely
> > >     different swizzles, and at the same time, the same swizzles were
> > > used for
> > >     completely different channel orders of 8bpc formats.
> > >     
> > >     This made the whole table self-contradicting, caused headaches,
> > > and last
> > >     but not least, incorrent rendering for the drivers relying on
> > > these swizzles.
> > > 
> > > I hope I got it right. I didn't make a special distinction between the
> > > array and arith layouts. All I did was to make sure that if I grep
> > > e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
> > > ones.
> > 
> > Hi Marek,
> > 
> > I'll need a bit more time to investigate this.
> > 
> > One problem is that the interpretation of the swizzle varies with array
> > vs arith. The ordering for array is the lowest significant word to the
> > highest significant word (where word for 8bit formats is a byte), where
> > for arith it goes from least significant bit to the highest significant
> > bit. This is the same difference as array indexation and bit shifts.
> > 
> > There is also the problem of byte order which affects the bit shift
> > interpretation... 
> > 
> > I admit thet the current format description table is terribly
> > underdocumented/confusing and likely broken in several ways. I wrote it
> > to be able to code generate pixel format translation (which is wroking
> > reasonably) and never expected people to use it for hardware drivers as
> > well, although it is perfectly legitimate use. 
> > 
> > I have my own interpretation of these concepts, you and others hw driver
> > writers have their own different interpretation. Furthermore in
> > draw/translate/util modules there are some inconsistencies in these
> > interpretations too. So I need to read the GL and DX10 specs very well,
> > see how current drivers are using the descriptions, and come up with
> > something that makes sense for everybody.
> > 
> > So please hold on to your patch for a couple of days.
> > 
> > I'd appreciate if the interested parties could take a good look to
> > u_format.h comments, and summarize what they think the format semantics
> > should be.
> > 
> > Jose
> 
> 
> There are two inconsistencies in formats ATM: 
> a) the notation used in PIPE_FORMAT_xxx, and 
> b) the values in util_format_description::swizzles .
> 
> 
> There's a D3D9 <-> D3D10 format conversion table  in 
> http://msdn.microsoft.com/en-us/library/ee415668(VS.85).aspx#Porting_Content
> and D3D9 <-> GL format table in
> http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/utils.c;hb=HEAD .
> 
> D3D10 dropped all arithmetically encoded formats, and inverted the
> swizzle notation (e.g., D3DFMT_A2B10G10R10 and  DXGI_FORMAT_R10G10B10A2
> are equivalent).
> 
> Gallium has to represent both kinds and mixes both notations (the
> MSB->LSB notation traditionally used for texture formats, the LSB->MSB
> for vertex declarations). So instead of the current inconsistencies,
> both on p_format.h and u_format.csv, I suggest we all normalize on one
> notation, lets say MSB->LSB for pixel/vertex formats.
> 
> For example, the vertex format
> 
>    struct vertex {
>       float x; 
>       float y;
>    };
> 
> should be described the format PIPE_FORMAT_G32R32_FLOAT (not the current
> PIPE_FORMAT_R32G32_FLOAT), which is equivalent:
> - D3D9's D3DFMT_G32R32F texture format
> - D3D9's D3DDECLTYPE_FLOAT2 vertex declaration type
> - D3D10's DXGI_FORMAT_R32G32_FLOAT
> - OpenGL's GL_RG32F format
> - OpenGL's glVertexAttrib2f attribute
> - OpenGL's glVertexPointer(2, GL_FLOAT, 0, 0);
> - etc.
> 
> 
> For the util_format_description::swizzles I suggest we always refer the
> swizzles from LSB->MSB.
> 
> 
> Leaving the interface change aside for now (Keith is away this week),
> unless somebody has a better suggestion I'll update at least the meaning
> of util_format_description::swizzles and u_format.csv to be consistent
> with this.

I'm finished with my u_format* cleanups for now. 

We have no unit tests for pixel formats yet so there might be some
regressions. Let me know. 

As said in the bottom of u_format.csv, there are the formats with
unclear / inconsistent semantics:

# Ambiguous formats
# FIXME: They are used with different meanings in different places!!!
PIPE_FORMAT_R8G8B8_UNORM          , plain, 1, 1, un8 , un8 , un8 ,     , zyx1, rgb
PIPE_FORMAT_R8G8B8A8_UNORM        , plain, 1, 1, un8 , un8 , un8 , un8 , wzyx, rgb

# Unused formats
# XXX: Couldn't find any state tracker using them!!
PIPE_FORMAT_B6G5R5_SNORM          , plain, 1, 1, sn5 , sn5 , sn6 ,     , xyz1, rgb
PIPE_FORMAT_R8G8B8X8_SNORM        , plain, 1, 1, sn8 , sn8 , sn8 , sn8 , wzy1, rgb
PIPE_FORMAT_R8G8B8X8_USCALED      , plain, 1, 1, u8  , u8  , u8  , u8  , wzy1, rgb
PIPE_FORMAT_R8G8B8X8_SSCALED      , plain, 1, 1, s8  , s8  , s8  , s8  , wzy1, rgb
# XXX: This one is mentioned in mesa and r300, but not anywhere else. Not sure it is actually needed
PIPE_FORMAT_R8G8B8X8_UNORM        , plain, 1, 1, un8 , un8 , un8 , un8 , wzy1, rgb

The former formats need to be split in two formats to unalias their
semantics, and the latter formats should probably be removed.

Jose