Hi Oded,
Is the r600g driver ready for the Gallium3D infrastructure of big endian
hosts or did you only solve the wrong colors problem?
Cheers,
Christian
On 04 August 2015 at 6:57 PM, Oded Gabbay wrote:
On Mon, Aug 3, 2015 at 6:40 PM, Emil Velikov <emil.l.veli...@gmail.com
<mailto:emil.l.veli...@gmail.com>> wrote:
Hi Oded,
On 2 August 2015 at 11:37, Oded Gabbay <oded.gab...@gmail.com
<mailto:oded.gab...@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
Oded
Curious if your work has any effect on the big endian + r600 issue
[1]. I believe Christian Zigotzky (Cc'ed) was very passionate about
getting his r600 working - perhaps he can give your patches a test ?
... just to make sure that things don't go even worse :)
Cheers,
Emil
[1] https://bugs.freedesktop.org/show_bug.cgi?id=72877
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
