Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1003
------- Additional Comments From [EMAIL PROTECTED] 2004-08-24 14:18 ------- Andreas, thanks for your last comment. I'm using a ATI FireGL 8800 (R200) on Xorg X11 6.8.0 RC2, but games like gl-117 and trackballs lock the X server hard just after a few seconds (only one application) I've also seen Bug 814 which is about hard locks with R200: http://freedesktop.org/bugzilla/show_bug.cgi?id=814 So maybe all this could be fixed by this patch? (I think so) I've done a Mesa CVS checkout as described on http://www.mesa3d.org/cvs_access.html and with cvs2cl from http://www.red-bean.com/cvs2cl/ I find two commits: 2004-08-17 22:10 anholt * src/mesa/drivers/dri/: r200/r200_ioctl.c, r200/r200_lock.h, radeon/radeon_ioctl.c, radeon/radeon_lock.h: Revert the move of lost_context setting to UNLOCK_HARDWARE that was done in the last commit. I've been convinced by keithw that it's sufficient, and put a note in the code about it. Close another race for state in the Clear functions. I made the situation worse in my last commit, but this should fix things. Might be a slight performance hit, which could be regained by splitting the R*_FIREVERTICES calls in r*Clear up so that the EmitState doesn't happen in a separate new cmdbuf. 2004-08-17 03:41 anholt * src/mesa/drivers/dri/: radeon/radeon_context.h, radeon/radeon_ioctl.c, radeon/radeon_ioctl.h, radeon/radeon_lock.h, radeon/radeon_state_init.c, radeon/radeon_swtcl.c, radeon/radeon_tcl.c, r200/r200_cmdbuf.c, r200/r200_context.h, r200/r200_ioctl.c, r200/r200_ioctl.h, r200/r200_lock.h, r200/r200_state_init.c, r200/r200_swtcl.c, r200/r200_tcl.c: Close some races with locking on R100 and R200 which could manifest as rendering errors on r100 and rendering errors and hangs on r200 (same for R100 without OLD_PACKETS). If a command buffer filled after some state (EmitState or a VBPNTR write) was emitted, the lock was grabbed, the buffer flushed, a new buffer prepared, and the lock dropped. Another client could come in, set its own state as part of rendering, and when the first client flushed the rendering commands depending on the previous state, it got the 2nd client's state. This is fixed by checking for enough space before beginning a set of state emits and rendering, and flushing the buffer first if so. This guarantees that the buffer won't wrap. Also, move the "lost_context = 1" from the end of cmdbuf flushing to UNLOCK_HARDWARE for clarity (at a minimum) that any time the lock is dropped, state may get overwritten. We don't have enough information at the point of the LOCK_HARDWARE to reset our state to the last UNLOCK_HARDWARE point in the case that we did lose our context, but saving the information to rebuild that state may be a useful optimization (ipers data suggests up to 5%). I've found that these two patches are included in X.Org CVS release 04-08-22. Versions before this did somewhat work, but this locks up completely. Some one of the changes applied to the tree lately even made things worse. But I also rebooted to newer kernel with new drm modules built from Xorg. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
