There seem to be at least two problems with fdo23670-drawpix_stencil (and other stencil tests) on r200. There is incorrect rendering, which bisects to the first commit listed below, and a crash, which bisects to the second. The backtrace of the segfault is: (gdb) bt #0 0x00007ffff5a2fd5f in radeon_unmap_renderbuffer_s8z24 (ctx=0x6992d0, rb=0x85d2d0) at radeon_fbo.c:270 #1 0x00007ffff5a2fe31 in radeon_unmap_renderbuffer (ctx=0x6992d0, rb=0x85d2d0) at radeon_fbo.c:290 #2 0x00007ffff5a40726 in radeon_renderbuffer_unmap (ctx=0x6992d0, rb=0x85d2d0) at radeon_span.c:510 #3 0x00007ffff5a408a8 in radeon_unmap_framebuffer (ctx=0x6992d0, fb=0x85cc50) at radeon_span.c:545 #4 0x00007ffff5a40a67 in radeonSpanRenderFinish (ctx=0x6992d0) at radeon_span.c:579 #5 0x00007ffff5d0d249 in swrast_render_finish (ctx=0x6992d0) at swrast/s_context.h:335 #6 0x00007ffff5d0f5ae in _swrast_DrawPixels (ctx=0x6992d0, x=50, y=50, width=20, height=20, format=6401, type=5121, unpack=0x6a8bb0, pixels=0x7fffffffdf30) at swrast/s_drawpix.c:750 #7 0x00007ffff5c0c9a6 in _mesa_meta_DrawPixels (ctx=0x6992d0, x=50, y=50, width=20, height=20, format=6401, type=5121, unpack=0x6a8bb0, pixels=0x7fffffffdf30) at drivers/common/meta.c:2217 #8 0x00007ffff5ca6311 in _mesa_DrawPixels (width=20, height=20, format=6401, type=5121, pixels=0x7fffffffdf30) at main/drawpix.c:131 #9 0x0000000000429ba0 in piglit_display () at /home/idr/devel/graphics/piglit/tests/bugs/fdo23670-drawpix_stencil.c:68 #10 0x0000000000429c51 in display () at /home/idr/devel/graphics/piglit/tests/util/piglit-framework.c:56 #11 0x00007ffff7b0db07 in ?? () from /usr/lib64/libglut.so.3 #12 0x00007ffff7b11269 in fgEnumWindows () from /usr/lib64/libglut.so.3 #13 0x00007ffff7b0dfe2 in glutMainLoopEvent () from /usr/lib64/libglut.so.3 #14 0x00007ffff7b0e8d5 in glutMainLoop () from /usr/lib64/libglut.so.3 #15 0x000000000042a3c0 in main (argc=1, argv=0x7fffffffe4b8) at /home/idr/devel/graphics/piglit/tests/util/piglit-framework.c:304 (gdb) print tiled_s8z24_map $1 = (uint32_t *) 0x7ffff4d09000 (gdb) print dst_offset $2 = 53288 (gdb) print untiled_s8z24_map $3 = (uint32_t *) 0x868b10 (gdb) print src_offset $4 = 256 (gdb) print tiled_s8z24_map[dst_offset/4] Cannot access memory at address 0x7ffff4d16028 (gdb) commit 345fc4161967f15fb80848cd7dc6a63100f8c12d Author: Eric Anholt <eric@anholt.net> Date: Wed Oct 12 17:05:20 2011 -0700 swrast: Convert color glReadPixels slow path to using MapRenderbuffer. This may be a bit slower than before because we're switching from per-format compiled loops in GetRow to _mesa_unpack_rgba_block_unpack's loop around a callback to unpack a pixel. The solution there would be to make _mesa_unpack_rgba_block fold the span loop into the format handlers. (On the other hand, function call overhead will hardly matter if MapRenderbuffer means the driver gets the data into cacheable memory instead of uncached). The adjust_colors code should no longer be required, since the unpack function does the 565 to float conversion in a single pass instead of converting it (poorly) through 8888 as apparently happened in the past. Reviewed-by: Brian Paul <brianp@vmware.com> commit 7d91ecf7a3a08c01a704f2d427444f7a97991680 Author: Dave Airlie <airlied@redhat.com> Date: Mon Dec 5 19:15:04 2011 +0000 radeon/r200: add draw/stencil buffer detiling This moves the detiling to the fbo mapping, r200 depth is always tiled, and we can't detile it with the blitter. Signed-off-by: Dave Airlie <airlied@redhat.com>
It looks like the misrendering was (briefly!) fixed by b2596c3 and broken again by f24e106 (two commits later).
Can you upgrade to a DDX from -git? I think the fix is in there, it was allocating too small depth buffers.
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=98b2d5fe1722a43c4bbe7711ed7180a3fb65305f this fix in particular.
(In reply to comment #2) > Can you upgrade to a DDX from -git? > > I think the fix is in there, it was allocating too small depth buffers. I can, but it won't be until next week. I'm currently traveling.
This test seems to work fine now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.