[Mesa-dev] [PATCH 03/13] gallium: Introduce 32-bit bytewise format names

[Michel Dänzer]

On Die, 2013-06-04 at 01:15 -0700, Jose Fonseca wrote:
> ----- Original Message -----
> > Michel Dänzer <michel at daenzer.net> writes:
> > > On Fre, 2013-05-24 at 09:11 -0700, Jose Fonseca wrote:
> > >> 
> > >> I agree that with non-array formats, like B5G6R5 and R5G6B5, replacing
> > >> them with endian-variant BGR565 and RGB565 makes a lot of sense (as
> > >> the swapped version will probably never be needed).
> > >> 
> > >> But I'm not sure about RGBA8 variants...
> > >> 
> > >>  - On one hand, it is often more efficient to read/write them as 32bit
> > >> integers than as an array of bytes.
> > >>  
> > >>  - On the other hand it is easier to think of then as an array of
> > >> bytes than an integer quantity.
> > >> 
> > >> One thing is clear -- a given format can't be both -- either it is
> > >> endianess-variant packed color or a endianness-invariant array color.
> > >
> > > Actually, I think it should be possible to make the RGBA8 variants
> > > usable as either an array of bytes or a packed integer, given the right
> > > setup of definitions and aliases (which would differ between little and
> > > big endian hosts). But I'm not sure offhand what would be the best way
> > > to achieve that for the util_format stuff.
> 
> This is only possible for little endian hosts. For big endian hosts,
> no format can be interpreted simultaneously as array or arithmetically
> packed integer, as the opposite ordering ensues. For example, 8bits
> red 8 bits green 8 bits blue 8 bits alpha, on big endian is four bytes
> with R G B A if seen as array, four bytes with A B G R if seen as
> packed integer. 

What I meant to say was that the same representation of a pixel in
memory can be described either as an array of bytes or as a packed
integer. Obviously, the description as a packed integer depends on the
host endianness. But it should still be possible for code to use one or
the other description, depending on what makes more sense in a given
context.


> I strongly recommend stepping back, and avoiding invasive (or any)
> semantic changes. Merely stick to add new things instead of changing
> the things already in there.  In particular, I suggest on a first
> stage to do the following:
> - introduce _new_ native endianness formats (RGB565, RGBA8888 and
> friends) as necessary
>   - do not alias these with anything
>   - do not change any of the of existing formats or their
> interpretation
> - introduce a new util_format_description::native_endianess or
> "packed_integer" for these new formats.
> - implement the new formats where needed (u_format, gallivm, llvmpipe,
> etc)
>   - introduce new paths for them "if
> (format_description->native_endianess) { ... } else { /* precisely the
> same as before */ }"

So far, so good.

> - use the new formats in mesa state tracker on big endian hosts
>   - leave little endian hosts alone until big endian work well

This makes little sense to me though, as in contrast to the existing
Gallium formats, the new formats will be perfect matches for the Mesa
formats.


> If you do this, we all can be sure that we won't break what's there
> while making progress on this issue: that is, it should improve
> support on big endian without any regressions on little endian.

Surely we can prevent / fix any regressions timely with piglit.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer