[Mesa-dev] gallium endianness and hw drivers

[Erik Faye-Lund]

On Wed, Jan 15, 2014 at 7:07 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On Die, 2014-01-14 at 00:22 +0100, Marek Olšák wrote:
>> I think the format conversion functions should look like:
>>
>> #ifdef BIG_ENDIAN
>>    case PIPE_FORMAT_A8B8G8R8_UNORM:
>>       return hw_format_for_R8G8B8A8_UNORM;
>> ...
>> #else
>>    case PIPE_FORMAT_R8G8B8A8_UNORM:
>>       return hw_format_for_R8G8B8A8_UNORM;
>> #endif
>>
>> which can be simplified to:
>>
>>    case PIPE_FORMAT_RGBA8888_UNORM:
>>       return hw_format_for_R8G8B8A8_UNORM;
>>
>> So that the GPU can see the same formats, but they are different for the CPU.
>>
>> What do you think?
>
> That might be an option, but PIPE_FORMAT_R8G8B8A8_UNORM is useful on big
> endian hosts as well, e.g. it matches GL_RGBA / GL_UNSIGNED_BYTE
> exactly.

Well, there's the added complication that GL_RGBA / GL_UNSIGNED_BYTE
can be specified with an unaligned pointer on architectures that does
not support unaligned reads (e.g ARM), and packed formats cannot. And
then there's GL_RGB / GL_UNSIGNED_BYTE which further messes the
treat-array-formats-as-if-they-were-packed strategy.

> I think one issue here is that we're trying to use a single format
> attribute for several purposes (API visible representation, GPU/driver
> internal representation).

Indeed, and if we stopped doing that, the issues above should be solvable.

I've actually been involved in the successful shipping of an OpenGL ES
2.0 implementation written for little-endian machines, on a big-endian
machine. But we had the benefit of being able to make
hardware-modifications, which made this a whole lot easier. IIRC, we
just made the texture-fetches and pixel-writes use native endianess.