On Wed, 2010-01-06 at 07:03 -0800, Michel Dänzer wrote: > 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.
Just to see if I have the right facts here: does ATI & NVIDIA hardware only support little endian 565 and 1555 formats, or do they also support the big endian formats too? Jose ------------------------------------------------------------------------------ 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
