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

Reply via email to