[Mesa-dev] Wrong colors in 3D apps on big-endian systems

[Richard Sandiford]

Christian Zigotzky <chzigotzky at xenosoft.de> writes:
> Am 11.03.14 12:08, schrieb Richard Sandiford:
>> Michel Dänzer <michel at daenzer.net> writes:
>>> On Mon, 2014-03-10 at 10:11 +0100, Christian Zigotzky wrote:
>>>> On 10.03.2014 02:49, Michel Dänzer wrote:
>>>>> Congratulations, you just broke llvmpipe again on big endian systems. ;)
>>>> I'm sorry but Mesa classic works very well on Debian Sid and Lubuntu
>>>> 14.04 with these changes. ;) Why does Mesa classic work with the
>>>> little-endian defines?
>>> What do you mean by 'Mesa classic'? The r600g driver works with the
>>> little endian defines because r600g assumes st/mesa uses the formats the
>>> way it did before the llvmpipe big endian fixes.
>>>
>>>>> Did you even look at the commits introducing those defines? Did you
>>>>> really think those defines, with explicit endianness checks, were
>>>>> introduced for no reason but to break drivers on big endian systems?
>>>>>
>>>>>
>>>>> I explained the problem in r600g and how it could be solved. Please
>>>>> explore that.
>>>> I'll try to explore that but I don't have any knowledge about the Mesa
>>>> source code. The Fedora guys have solved the problem with the patch
>>>> "mesa-9.2-llvmpipe-on-big-endian.patch". What do you think of this patch?
>>> It sounds like an older downstream attempt at fixing llvmpipe on big
>>> endian hosts, which was superseded by the upstream fixes, which were
>>> incidentally pushed by the 'Fedora guy' Adam Jackson. Adding him and
>>> Richard Sandiford (the author of the fixes) to CC, maybe they can help
>>> you fix up r600g.
>> I don't know the r600 code at all, sorry.  But like you say, if the code
>> is treating the x8y8z8w8 formats as low-to-high integers (x in lsb, z in msb)
>> then the right fix should be to use PIPE_FORMAT_xyzw8888_* instead of
>> PIPE_FORMAT_x8y8z8w8_*.
>>
>> Thanks,
>> Richard
>>
>>
> Richard,
>
> How can I change the formats x8y8z8w8 to xyzw8888?

I just mean changing instances of things like PIPE_FORMAT_A8R8G8B8_UNORM
to PIPE_FORMAT_ARGB8888_UNORM in the relevant parts of the r600 support
(which is I think what Michel also meant -- like I say, I'm not really
adding anything new here).  PIPE_FORMAT_ARGB8888_UNORM always has the
alpha channel in the low bits of a 32-bit int according to host endianness,
whereas PIPE_FORMAT_A8R8G8B8_UNORM always has the alpha channel in the
first byte of memory.

I can't say for sure which the "revelavant parts" are because I don't
know the r600 code.

Thanks,
Richard