On Tue, 2009-07-28 at 16:32 +0100, José Fonseca wrote:
> 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
The exact naming scheme isn't really important. What's important is that
it defines a format unambiguously.
> > 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;"
Yes, for example.
> 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.
Exactly, in cases like that it might help matching native and non-native
formats. Maybe don't actually add all those from the beginning, but make
sure the scheme is expressive enough to allow them to be added later on.
--
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
