[Mesa-dev] Gallium pixel formats on big-endian

[Jose Fonseca]

----- Original Message -----
> On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
> > 
> > ----- Original Message -----
> > > On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote:
> > > > 
> > > > ----- Original Message -----
> > > > > On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote:
> > > > > > I've been looking at untangling the pixel format code for
> > > > > > big-endian.
> > > > > > My current theory is that blindly byte-swapping values is
> > > > > > just
> > > > > > wrong.
> > > > > 
> > > > > Certainly. :) I think you're discovering that this hasn't
> > > > > really
> > > > > been
> > > > > thought through beyond what's necessary for things to work
> > > > > with
> > > > > little
> > > > > endian CPU and GPU. Any code there is for dealing with big
> > > > > endian
> > > > > CPUs
> > > > > has been bolted on as an afterthought.
> > > > 
> > > > My memory is a bit fuzzy, but I thought that we decided that
> > > > gallium
> > > > formats were always defined in terms of little-endian, which is
> > > > why
> > > > all need to be byte-swapped. The state tracker was the one
> > > > responsible
> > > > to translate endian-neutral API formats into the non-neutral
> > > > gallium
> > > > ones.
> > > 
> > > I know that was the suggested solution when this was discussed
> > > previously, but I'm still not really convinced that cuts it. Just
> > > for
> > > one example, last time in
> > > 864e97f3-352a-4fdb-9bb7-6d41a1969ccd at zimbra-prod-mbox-2.vmware.com
> > > you
> > > seemed to agree it doesn't make sense for vertex elements.
> > 
> > I couldn't find it by id, but I think you mean:
> > 
> >   http://lists.freedesktop.org/archives/mesa-dev/2011-April/007109.html
> > 
> > Yes, that's right. (I did say my memory was fuzzy :)
> 
> Yeah, that's what I was referring to.
> 
> 
> > > For another example (which I suspect is more relevant for this
> > > thread),
> > > wouldn't it be nice if the software rendering drivers could
> > > directly
> > > represent the window system renderbuffer format as a Gallium
> > > format
> > > in
> > > all cases?
> > 
> > I'm missing your point, could you give an example of where that's
> > currently not possible?
> 
> E.g. an XImage of depth 16, where the pixels are generally packed in
> big
> endian if the X server runs on a big endian machine. It's impossible
> to
> represent that with PIPE_FORMAT_*5*6*5_UNORM packed in little endian.

I see.

Is this something that could be worked around?

> > > I can't help feeling it would be better to treat endianness
> > > explicitly
> > > rather than implicitly in the format description, so drivers and
> > > state
> > > trackers could choose to use little/big/native/foreign endian
> > > formats
> > > as
> > > appropriate for the hardware and APIs they're dealing with.
> > 
> > What you mean by explicitly vs implicitly? Do you mean r5g6b5_be,
> > r5g6b5_le, r32g32b32a32_unorm_le, r32g32b32a32_unorm_be, etc?
> 
> Yeah, something like that, with the byte order only applying within
> each
> component for array formats.

I don't oppose that. But it does seem a lot of work.


How would hardware drivers handle this? Specially those that have a single LE/BE bit to choose?

(BTW, I do believe we should unify Mesa format handling and Gallium's u_format module into a shared external helper library for formats before we venture into that though as the effort of doing that would pretty much double.


I think it is also worth considering the other extreme: all formats are expected to be LE on LE platforms, BE on BE platforms. Is this feasible, or are there APIs that need (i.e, require) to handle both LE/BE formats? (Or hardware only capable of LE formats?) If not, would it be feasible to byte-swap at state tracker level?


In short, in order to support BE platforms properly, there will be some pain regardless the approach we take. I really don't feel strongly about any approach -- just want a level of pain we (ie. the whole community) can sustain. Because if the "right thing" is onerous and few care I suspect this will quickly rot or never get completed.


Jose