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.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
