José Fonseca wrote:
> On Tue, 2009-07-28 at 08:30 -0700, Brian Paul wrote:
>> Michał Król wrote:
>>> José Fonseca pisze:
>>>> I found one other problem in the way we use 4 x 8bit color formats:
>>>> sometimes we interpret them as arithmetically coded in an unsigned (e.g
>>>> src/gallium/auxiliary/util/u_tile.c when reading/writing
>>>> color/depth/stencil buffers), sometimes we interpret them (e.g.
>>>> src/gallium/auxiliary/translate/translate_generic.c when reading/writing
>>>> vertex buffers). And these actually mean different things on
>>>> little-endian architectures.
>>>>
>>>>
>>> Some text is missing from the first sentence. I am guessing that
>>> sometimes we interpret them as an array of bytes, right?
>>>
>>>> I think the only viable option is to distinguish between these two kinds
>>>> in the cases where it is ambiguous, like
>>>>
>>>> PIPE_FORMAT_R8G8B8A8_UNORM /* a | ( b << 8) | (g << 8) | (r << 24) */
>>>> PIPE_FORMAT_RGBA8_UNORM /* {r, g, b, a} */
>>>>
>>>> Since there are legitimate uses in for both (color buffers, and vertex
>>>> buffers).
>>>>
>>>> Anybody has better ideas?
>>>>
>>> We should go with and stick to a single convention. I don't know, maybe
>>> for example this:
>>>
>>> A16R16G16B16
>>>
>>> The format description above would indicate that we are dealing with a
>>> 64-bit entity with bits being numbered from right to left. That would
>>> mean the B component occupies first 16 bits (bytes 0:1), the G component
>>> next 16 bits (bytes 2:3) and so on. Because there is no implied dword
>>> and encoding using shifts, we could easily write some code that decodes
>>> the format in a portable way across LE and BE architectures.
>> When I've worked on this stuff in the past, the convention I was
>> following was:
>>
>> IF total pixels size <= 32 bits THEN
>> Treat the pixel as a uint, ushort or ubyte where the components
>> are listed in MSB to LSB order. Individual components are
>> accessed with bit shifts and masks.
>> ELSE
>> Components are listed in "array" order and accessed as an array.
>>
>> It would be consistant to use the array style everywhere but that
>> doesn't really work for a format like RGB565 or Z24S8.
>
> This rule still leads to weird cases. For example, to express arrays of
> 16bits integers one would use
>
> PIPE_FORMAT_R16_USCALED
> PIPE_FORMAT_G16R16_USCALED <= odd
> PIPE_FORMAT_R16G16B16_USCALED
> PIPE_FORMAT_R16G16B16A16_USCALED
Yeah, the predicate I used above isn't really a "rule", but I think
you get the gist of it.
-Brian
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
