On Wed, 2010-02-24 at 08:19 -0800, José Fonseca wrote: > 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.
I've done with the pipe format cleanup: - removing duplicate formats with same semantics - un-aliased different formats with the same name - standardize on LSB->MSB swizzle notation (it seemed to gather more consensus, and is used D3D10 and many places) - ditto for YUV formats Jose ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
