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