Bug 64091

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 :

mesa/src/gallium/drivers/r600/r600_blit.c

r600_blit_decompress_depth()

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:
http://lists.freedesktop.org/archives/mesa-dev/2013-January/033590.html
http://lists.freedesktop.org/archives/mesa-dev/2013-February/034047.html

(In reply to comment #6)
> Gallium is big endian safe at the moment.  See these discussion threads for
> what needs to be done:
> http://lists.freedesktop.org/archives/mesa-dev/2013-January/033590.html
> http://lists.freedesktop.org/archives/mesa-dev/2013-February/034047.html

*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.