Michel Dänzer wrote on 2010-01-06 15:23: > 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... > > Interesting. Is there any reference that would say which formats are 'array', and which are not? Or is it a simple rule that when every component's bitsize is greater-or-equal to, say, 16, then it's an array format?
------------------------------------------------------------------------------ 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
