On Tue, 2009-07-28 at 17:36 +0200, Michał Król wrote:
> José Fonseca pisze:
> > 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.
> >
> >
> I don't think they follow them everywhere. But the point is we can just
> look at GL spec, see the convention and try to match it to a gallium format.
>
> > 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.
> >
> >
> Well, yes and no. Let's break A1R5G5B5 into bits using my definition.
>
> 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
> A R R R R R G G G G G B B B B B
>
> It means B is in byte 0, G in bytes 0 and 1, R and A are in byte 1. To
> extract them correctly you need to use masking and shifting wisely, but
> because you do it on a byte level, you are not concerned about
> endianness, as endianness is about byte ordering in a word, not bit
> ordering in a byte. The concept of a word does not exist here.
But if you look at it in non-native byte order, it becomes
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
G G G B B B B B A R R R R R G G
So essentially it'd have to allow for disjoint ranges of bits in
different bytes for any given component. Not sure that's very practical.
I agree with José that formats like that should always be treated as
packed, with optional non-native byte order.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------------------------------------------------------
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
