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
> Note that this issue is similar to OpenGL's "regular" pixel types such
> as GL_UNSIGNED_BYTE and GL_UNSIGNED_SHORT vs. the "packed" pixel types
> such as GL_UNSIGNED_INT_8_8_8_8 and GL_UNSIGNED_SHORT_5_6_5.
Yes.
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
