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

Reply via email to