José Fonseca wrote on 2010-01-06 15:26: > On Wed, 2010-01-06 at 06:11 -0800, michal wrote: > >> José Fonseca wrote on 2010-01-06 15:03: >> >>> 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. >>> >>> >>> >> I did this because in the other thread you defined arith layout to apply >> to 32-or-less-bit formats. Since I still believe arith and array layout >> are somewhat redundant, we can go the other way round and convert other >> arith layouts to array, save for 16-or-less-bit formats. >> > > Indeed arith applies to 32-or-less-bit formats, but I never meant to say > that all 32-or-less-bit formats must be in arith. > >
Understood. > They are indeed redundant, but array is/will be more efficient and when > code generation is more robust and big-endian-safe all x8, x8x8, x8x8x8, > x8x8x8x8x8 formats will be likely in array layout. > > That is okay, we agree on that part. The question is what is the reason we treat PIPE_FORMAT_R8G8B8A8_UNORM as having array layout (before my patch), and e.g. PIPE_FORMAT_B8G8R8A8_UNORM as having arith layout? ------------------------------------------------------------------------------ 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