On Wed, 2010-01-06 at 15:51 +0100, Michel Dänzer wrote: > On Wed, 2010-01-06 at 14:32 +0000, José Fonseca wrote: > > On Wed, 2010-01-06 at 06:23 -0800, Michel Dänzer wrote: > > > On Wed, 2010-01-06 at 14:03 +0000, José Fonseca wrote: > > > > On Tue, 2010-01-05 at 23:36 -0800, michal wrote: > > > > > michal wrote on 2010-01-06 07:58: > > > > > > michal wrote on 2009-12-22 10:00: > > > > > > > > > > > >> Marek Olšák wrote on 2009-12-22 08:40: > > > > > >> > > > > > >> > > > > > >>> Hi, > > > > > >>> > > > > > >>> I noticed that gallium/auxiliary/util/u_format.csv contains some > > > > > >>> weird > > > > > >>> swizzling, for example see this: > > > > > >>> > > > > > >>> $ grep zyxw u_format.csv > > > > > >>> PIPE_FORMAT_A8R8G8B8_UNORM , arith , 1, 1, un8 , un8 , un8 > > > > > >>> , > > > > > >>> un8 , zyxw, rgb > > > > > >>> PIPE_FORMAT_A1R5G5B5_UNORM , arith , 1, 1, un5 , un5 , un5 > > > > > >>> , > > > > > >>> un1 , zyxw, rgb > > > > > >>> PIPE_FORMAT_A4R4G4B4_UNORM , arith , 1, 1, un4 , un4 , un4 > > > > > >>> , > > > > > >>> un4 , zyxw, rgb > > > > > >>> PIPE_FORMAT_A8B8G8R8_SNORM , arith , 1, 1, sn8 , sn8 , sn8 > > > > > >>> , > > > > > >>> sn8 , zyxw, rgb > > > > > >>> PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 > > > > > >>> , u8 > > > > > >>> , zyxw, srgb > > > > > >>> > > > > > >>> It's hard to believe that ARGB, ABGR, and BGRA have the same > > > > > >>> swizzling. Let's continue our journey: > > > > > >>> > > > > > >>> $ grep A8R8G8B8 u_format.csv > > > > > >>> PIPE_FORMAT_A8R8G8B8_UNORM , arith , 1, 1, un8 , un8 , un8 > > > > > >>> , > > > > > >>> un8 , zyxw, rgb > > > > > >>> PIPE_FORMAT_A8R8G8B8_SRGB , arith , 1, 1, u8 , u8 , u8 > > > > > >>> , > > > > > >>> u8 , wxyz, srgb > > > > > >>> > > > > > >>> Same formats, different swizzling? Also: > > > > > >>> > > > > > >>> $ grep B8G8R8A8 u_format.csv > > > > > >>> PIPE_FORMAT_B8G8R8A8_UNORM , arith , 1, 1, un8 , un8 , un8 > > > > > >>> , > > > > > >>> un8 , yzwx, rgb > > > > > >>> PIPE_FORMAT_B8G8R8A8_SRGB , arith , 1, 1, u8 , u8 , u8 > > > > > >>> , > > > > > >>> u8 , zyxw, srgb > > > > > >>> > > > > > >>> Same formats, different swizzling? I don't really get it. And > > > > > >>> there's > > > > > >>> much more cases like these. Could someone tell me what the > > > > > >>> intended > > > > > >>> order of channels should be? (or possibly propose a fix) The > > > > > >>> meaning > > > > > >>> of the whole table is self-contradictory and it's definitely the > > > > > >>> source of some r300g bugs. > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >> Marek, > > > > > >> > > > > > >> Yes, that seems like a defect. The format swizzle field tells us > > > > > >> how to > > > > > >> "swizzle" the incoming pixel so that its components are ordered in > > > > > >> some > > > > > >> predefined order. For RGB and SRGB colorspaces the order is R, G, > > > > > >> B and > > > > > >> A. For depth-stencil, ie. ZS color space the order is Z and then S. > > > > > >> > > > > > >> I will have a look at this. > > > > > >> > > > > > >> > > > > > > Marek, Jose, > > > > > > > > > > > > Can you review the attached patch? > > > > > > > > > > > > > > > > Ouch, it looks like we will have to leave 24-bit (s)rgb formats with > > > > > array layout as the current code generator will bite us on big endian > > > > > platforms. Attached an updated patch. > > > > > > > > Why are you changing the layout from array to arith? Please leave that > > > > alone. > > > > > > > > Yes, the code generator needs a big_ending -> little endian call to be > > > > correct on big endian platforms, as gallium formats should always be > > > > thougth of in little endian terms, just like most hardware is. > > > > > > Actually, 'array' formats should be endianness neutral, > > > > Yep. > > > > > and IMO 'arith' formats should be defined in the CPU endianness. > > > > I originally thought that too, but Keith convinced me that "gallium is a > > hardware abstraction, and all 3d hardware is little endian, therefore > > gallium formats should be always in little endian." > > Then there probably should be no 'arith' formats, at least not when the > components consist of an integer number of bytes.
... and at least for some others, e.g. 16 bit 565 or 1555 formats, 'always little endian' would mean that some API formats couldn't be represented by Gallium formats on big endian CPUs. So there would have to be a 'reverse byte order' bit at least. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
