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

Reply via email to