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

[Jose Fonseca]

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

Jose