On Tue, 2009-07-28 at 07:02 -0700, 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} */
What is the usage for the second case? I suspect that it should be
converted to have a compile-time switch between RGBA and ABGR depending
on cpu endian-ness.
Keith
------------------------------------------------------------------------------
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
