[Mesa-dev] [PATCH 2/2] mesa: _mesa_format_convert should be endian agnostic

[Oded Gabbay]

On Fri, Aug 7, 2015 at 8:55 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 4 August 2015 at 17:57, Oded Gabbay <oded.gabbay at gmail.com> wrote:
>>
>>
>>
>> On Mon, Aug 3, 2015 at 6:40 PM, Emil Velikov <emil.l.velikov at gmail.com>
>> wrote:
>>>
>>> Hi Oded,
>>>
>>> On 2 August 2015 at 11:37, Oded Gabbay <oded.gabbay at gmail.com> wrote:
>>> > This patch fixes a bug that is manifested in the read path of mesa when
>>> > running on big-endian machines. The effects can be seen when running
>>> > piglit sanity test and/or taking a screen capture.
>>> >
>>> > The bug is caused when _mesa_format_convert receives src_format as
>>> > mesa_format, which it thens changes to mesa_array_format. During this
>>> > change, it checks for endianness and swaps the bytes accordingly.
>>> > However, because the bytes are _already_ swapped in the memory itself
>>> > (being written there by llvmpipe), and src_format value matches the
>>> > _actual_ contents of the memory, the result of the read is wrong.
>>> >
>>> I'm assuming that you're looked at swrast + softpipe as well - do they
>>> use the same approach or is llvmpipe the odd one out ?
>>>
>> Hi Emil,
>>
>> I checked it with swrast, softpipe AND llvmpipe.
>> Without my patch, all methods fail piglit sanity on ppc64
>> With my patch, all methods pass piglit sanity
>>
> I've mentioned the other drivers, as your commit message explicitly mentions
> llvmpipe alone. Perhaps dropping that hunk or adding the other two would be
> ok ? Props for checking all the drivers though !
>
Of course, thanks for reminding me to add it to the commit message.
I'll resend the patch shortly.


> I'm afraid that I've never looked into the BE codepaths so don't know how
> useful of a review I can do here.
So maybe just acked-by ?

Oded

>
> Emil
>