On Tue, 2009-07-28 at 08:21 -0700, Michel Dänzer wrote:
> On Tue, 2009-07-28 at 15:02 +0100, José Fonseca wrote:
> > On Mon, 2009-07-27 at 04:26 -0700, José Fonseca wrote:
> > > When pushing a new branch only the last commit message email gets sent,
> > > but there is one earlier patch submitted to the gallium-llvmpipe branch
> > > which I'd like to draw your attention to.
> > >
> > > The patch is attached -- it adds a new table describing pipe_formats in
> > > detail, automatically generated from a compact text file (.CSV) by a
> > > python script.
> > >
> > > Although pipe_format enum already has much of this information
> > > when I started drafting the LLVM IR code generation to unpack/pack a
> > > pixel using the format query functions p_format.h I soon stumbled into
> > > several problems:
> > > - swizzles are inconsistently used -- sometimes the swizzle describes
> > > which output vector channel goes in the source vector, sometimes it
> > > describes the opposite
> > > - depth stencil information is coded in the swizzle, instead of being
> > > coded as a new layout (which doesn't make any sense if o)
> > > - padding in the source vector is not properly respected in some cases
> > > - swizzles in integer format sometimes assume the source components
> > > start from the least significant bit, other times from the most
> > > significant bit
> > >
> > > The odd thing is that if one looks to an individual format, it looks OK.
> > > It is when you try to derive some rule that everything falls apart.
> > >
> > > Although some of the inconsistencies are straight forward to fix, there
> > > simply are not enough bits in an enum to store all this info
> > > conveniently with bitmask -- we'd have to resort to arithmetic
> > > operations instead. And even if we could, it would be a matter of time
> > > until some new format comes along and we need to devise a new way to
> > > encode it. It basically makes the goal of providing some sort of gallium
> > > binary compatibility impossible.
> > >
> > > A lookup table is way more flexible way to store this information, and
> > > can be just as fast to lookup, especially if one has the formats
> > > sequentially enumerated from 0, which I think we should do, once this
> > > code is complete enough to fully replace p_format.h's auxiliary
> > > functions.
> > >
> > > Note that the CSV was derived from p_format.h and still as
> > > inconsistencies for many of the formats. I hope to squash these soon by
> > > writing a small test suite with (packed, unpacked) pixel data pairs.
> > >
> > > I also hope to apply the same concept to automatically generate the
> > > functions the functions in u_tile.c, so that we don't have unsupported
> > > formats or bugs/typos lurking in that code, as often happens.
> > >
> > > Let me know if you disagree or have a better suggestion.
> >
> > 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.
> >
> > 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?
>
> I'm not sure I fully understand the distinction above,
Probably too subtle. My idea was that arrays by definition have all the
same number of bits, so you can factor out the bitsize to last. We could
also have
PIPE_FORMAT_R8_G8_B8_A8_UNORM
or some prefix
PIPE_FORMAT_R8G8B8A8_UNORM_ARRAY
Jose
> but FWIW it would
> probably be nice to have both packed formats (where the components are
> defined via shifts/masks in a larger integer) and unpacked formats
> (where the components are treated as an array of integer/float types)
> explicitly. Then it might also be nice to have packed formats (and
> possibly unpacked ones with components larger than one byte; otherwise
> the machine byte order shouldn't matter) with non-native byte order.
You mean formats like PIPE_FORMAT_R16G16_USCALED, i.e., "uint16_t r, g;"
I don't think non native order in this case matters in practice, unless
you're tracing into persistent storage, or transmitting across the wire.
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
