On Tue, 2009-07-28 at 16:25 +0100, José Fonseca wrote:
> 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.

Which bit 0? ;) (It's the MSB in PowerPC assembly)

Seriously tough, the point is that I think we should err on the side of
making it too explicit rather than too implicit.


-- 
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

Reply via email to