Re: [Dri-devel] mesa test failures with radeon (7200)

[Brian P. <br...@tu...>]

Roland Scheidegger wrote:
> Just for fun, tried all mesa demos/tests etc. with a radeon 7200 sdr.
> 
> redbook/alpha3d: nothing is seen unless a is pressed (and then only for 
> a very short time, buffering problem? (same as with r200)
> 
> samples/fog: the red part seems to have the fog applied quite 
> differently than with software mesa.
> 
> samples/prim: the top right rectangle (I believe that's the quad strip) 
> has a wrong color pattern (both with smooth and flat shade model, 
> correct with poly line mode which uses fallback) - assuming that 
> software mesa is correct of course, I have really no idea...
> Also, cycling through the colors, the original color pattern will never 
> come back with software mesa - it will be completely blue instead. This 
> works correctly with hardware acceleration.
> 
> samples/tri: basically works, but seems to trigger a bug in software 
> mesa (with LD_LIBRARY_PATH pointing to the standalone Mesa GL lib) for 
> some reason sometimes. I couldn't figure out what keys need to be 
> pressed exactly to trigger the bug, but it seems quite easy to 
> reproduce.  It will chew up all memory until the kernel kills it. At one 
> time I was able to get some gdb output, looks the crash reason is some 
> recursive loop:
> #0  0x40210172 in _tnl_copy_pv () from ../../lib/libGL.so.1
> #1  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
> #2  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
> #3  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
> #4  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
> #5  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
> #6  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
> #7  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
> #8  0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1
> #9  0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1
> (continued almost indefinitely, gdb was unable to get the outermost 
> frames unfortunately)
> Doesn't seem to happen with hardware acceleration, but I'm not sure.

Keith fixed this today.


> xdemos/wincopy: second window empty (or random content) (same as with r200)
> 
> seccolor: crashes with
> seccolor: radeon_state.c:741: radeonUpdateSpecular: Assertion `(p & (1 
> << 21)) == 0' failed
> #3  0x401bf42f in __assert_fail () from /lib/i686/libc.so.6
> #4  0x40598425 in radeonUpdateSpecular (ctx=0x8059a98) at 
> radeon_state.c:741
> #5  0x404a5608 in _mesa_set_enable (ctx=0x8059a98, cap=33880, state=1 
> '\001')
>     at enable.c:991
> #6  0x404a78cd in _mesa_Enable (cap=33880) at enable.c:1012
> (this bug can also be triggered by demos/spectex)
> The assertion fails because the derived mesa state ctx->_TriangleCaps 
> will only get calculated later. Removing the assertion makes seccolor 
> work correctly.
> 
> stencilwrap: fails every test (always returns 0 or 255, respectively).
> 
> I also get:
> glxinfo: radeon_tex.c:696: radeonDeleteTexture: Assertion `t' failed.
> as well as application crashes when OGL applications (for instance 
> QuakeIII) exit (this problem was present with r200 too but has already 
> been fixed?).

I've removed the assertion in DeleteTexture (restoring the code to as 
it was a couple weeks ago).

-Brian