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.
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?).
Roland
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
