From: Brian P. <br...@tu...> - 2004-01-26 23:58:39
|
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 |