On Tue, 2009-07-28 at 08:09 -0700, 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?
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.
Are these semantics followed by GL? (D3D does't matter much since it is
only used on x86 anyway). Because if not we need to choose different
formats according to the endianness.
Note also that formats like A1R5G5B5 can only be defined in terms of
shits. Furthermore, the channel that starts from bit 0 is B, and not A
as one would conclude from the your rule above.
Jose
------------------------------------------------------------------------------
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
