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

[Michel Dänzer]

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. 


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?


FWIW, https://bugs.freedesktop.org/show_bug.cgi?id=43698 has a start for
cleaning up the code relevant for r300g according to the 'always little
endian' policy. Note that as is this would break e.g. r600g on big
endian hosts, which currently relies on the status quo that the state
tracker code effectively treats the Gallium formats as being in host
byte order. I suspect the same might be true for the nouveau drivers.


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. 


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