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, and IMO 'arith' formats should be defined in the CPU endianness. Though as discussed before, having 'reversed' formats defined in the other endianness as well might be useful. Drivers which can work on setups where the CPU endianness doesn't match the GPU endianness should possibly only use 'array' formats, but then there might need to be some kind of mapping between the two kinds of formats somewhere, maybe in the state trackers or an auxiliary module... -- 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
