On 06.01.2010 08:36, 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. > It looks like I always thought how to interpret the formats now.
Which means the vertex element formats in mesa/state_tracker/st_draw.c should be corrected - the R8G8B8A8 and R8G8 vertex elements should be reversed, and the BGRA format should be A8R8G8B8. At least this would fix my (gallium/drivers/nv50/nv50.vbo) if (desc->swizzle[0] == UTIL_FORMAT_SWIZZLE_Z) /* BGRA */ check. Christoph > > > ------------------------------------------------------------------------------ > 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 >
------------------------------------------------------------------------------ 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
