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

[Jose Fonseca]

----- Original Message -----
> 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.

It was meant merely a stepping stone, and not an end goal.  A mean to get things committed and working on big endian platforms sooner rather than later.  If you want to skip this step, and hook new formats into mesa for both littel/big endian platforms straight away I won't oppose.  But due diligence (testing & reviewing) will take longer time, and leaving the old format translation code around should be trivial, so I don't see what benefit is achieved by skipping this step.  Either way, as you you/Richard prefer.

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

I'm not so sure about that.  Note I'm not doubting people's good faith in any way -- simply reflecting upon the several (some widely) different things we already proposed so far, I believe it is quite easy to dig a hole around us from which is not easy to get out.  That is, even though people want to act quickly, it's not clear what action to take...

Jose