I'm performing the bring-up of a Radeon adapter (AMD FirePro 2270) using Fedora 19 on a ppc64 machine, and running the sanity test profile from piglit the glean/readPixSanity testcase fails. I've also run the test with LIBGL_ALWAYS_SOFTWARE=1 and it fails some of the tests, so it might indicate that the problem is not on the Radeon Mesa driver itself.
I will attach to this bug the output from glxinfo and glean/readPixSanity for both Radeon driver and software rasterizer.
Steps to reproduce:
1. Install piglit
2. Run: # ./piglit-run.py tests/sanity.tests results/sanity.results
Created attachment 78661 [details]
glxinfo using the radeon driver
Created attachment 78662 [details]
readPixSanity output using the radeon driver
Created attachment 78663 [details]
glxinfo using software rasterizer
Created attachment 78664 [details]
readPixSanity output using software rasterizer
For radeon my guess is that depth/stencil readback needs some fiddling with texture format :
surf_tmpl.format = flushed_depth_texture->resource.b.b.format;
i would look at what format you got there and what try to play with some other format.
Gallium is big endian safe at the moment. See these discussion threads for what needs to be done:
(In reply to comment #6)
> Gallium is big endian safe at the moment. See these discussion threads for
> what needs to be done:
*Gallium is NOT big endian safe at the moment.
It's unlikely that both drivers are affected by one and the same problem. Let's start looking at this from the r600g driver first and work our way up the stack as necessary. :)
The r600g driver has been working around the issues pointed out by Alex using GPU byte-swapping facilities, but that obviously isn't working for depth/stencil readback.
You can look for R600_BIG_ENDIAN in r600 driver code for place where we program the hw depending on endianess.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/434.