[Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g)

[Jose Fonseca]

----- Original Message -----
> On Die, 2011-04-19 at 04:50 -0700, Jose Fonseca wrote:
> > ----- Original Message -----
> > > From: "Michel Dänzer" <michel at daenzer.net>
> > > To: "Cédric Cano" <ccano at interfaceconcept.com>
> > > Cc: "icthj" <tjourdan at interfaceconcept.com>,
> > > mesa-dev at lists.freedesktop.org
> > > Sent: Tuesday, April 19, 2011 10:39:41 AM
> > > Subject: Re: [Mesa-dev] [PATCH] Big endian support for RV730
> > > (Gallium r600g)
> > > 
> > > [ Moving to the mesa-dev list ]
> > > 
> > > On Fre, 2011-04-15 at 18:20 +0200, Cédric Cano wrote:
> > > > 
> > > > Here you are a patch that adds big endian support for rv730 in
> > > > r600
> > > > gallium driver.
> > > > 
> > > > I used the mesa-demos to test the driver status on big endian
> > > > platform.
> > > > Except with demos using accumulation buffer, the rendering is
> > > > the
> > > > same
> > > > as on Intel platform. Albeit there are still some artefacts
> > > > with
> > > > some
> > > > demos.
> > > > 
> > > > I manage to fix accumulation buffer demos but then,
> > > > glReadPixels
> > > > demos
> > > > won't work. I still can figure out (like with r600c) what and
> > > > when
> > > > I
> > > > must enable swap. It will depends on object's domains. That's
> > > > what
> > > > I
> > > > tried to do in r600_cb and r600_create_sampler_view.
> > > 
> > > That's probably because it hasn't been fully thought through yet
> > > how
> > > to
> > > deal with big endian CPUs vs. little endian GPUs in Gallium. When
> > > this
> > > was discussed previously, the basic rule decided was that all
> > > data
> > > passed across the Gallium driver interface was supposed to be
> > > little
> > > endian. That should probably be feasible in general for at least
> > > 'standard' pixel formats, but I'm afraid it doesn't really work
> > > for
> > > vertex data[0], which could be fed from the application (which
> > > will
> > > use
> > > CPU native byte order) to the GPU more or less directly.
> > > 
> > > Maybe byte order should be handled explicitly by the Gallium
> > > format
> > > definitions, and then it would be up to the state tracker to use
> > > the
> > > appropriate byte order formats. José, have you had any further
> > > thoughts
> > > on this?
> > 
> > I'm not sure either.  The design principle we've used in the past
> > for
> > this in the past is to match what the hardware can and cannot do.
> >  It
> > appears from Cédric's patch that r600 is able to toggle between
> > bit/little ending values in vertices.  Vertex/index buffers are
> > indeed
> > special because, unlike pixel data, the types can only be inferred
> > at
> > draw time, and not at data upload, so transcoding at
> > BufferMap/BufferData is not really feasible.
> > 
> > Does other hardware allow to toggle vertex data reads between
> > little/big endian?  If so then perhaps a per-vertex-element state
> > bit
> > indicating endianness might be sensible.
> 
> Unfortunately, older Radeons can't do that TTBOMK. They only have a
> single vertex fetcher byte-swapping field, which applies to all
> vertex
> data (but only if it's fetched from outside of VRAM).
> 
> Is there any scenario where vertex data wouldn't use the CPU's native
> byte order though?

Not really.  I suppose that making it explicit that vertex data is always assumed to be in the native byte order would make both driver implementation easy, and draw module implementation too.

> Anyway, it sounds like Cédric is still having issues with pixel data
> as
> well.

I don't know what the problem may be.  The semantics of some pixel formats are a bit tricky: e.g., while R8G8B8A8 has a reverse byte order equivalent (A8B8G8R8), other formats e.g., R5G6B5, do not.  I also don't know how much of this problem comes from the GL API, or is self inflicted by the Mesa state tracker or Gallium abstraction.

Can hardware easily toggle the byte order of pixel data as well?

Jose