I've been wondering a bit about this code in
radeon_emit_packet3_cliprect():
do {
if ( i < cmdbuf->nbox ) {
[...]
/* FIXME The second and subsequent times round
* this loop, send a WAIT_UNTIL_3D_IDLE before
* calling emit_clip_rect(). This fixes a
* lockup on fast machines when sending
* several cliprects with a cmdbuf, as when
* waving a 2D window over a 3D
* window. Something in the commands from user
* space seems to hang the card when they're
* sent several times in a row. That would be
* the correct place to fix it but this works
* around it until I can figure that out - Tim
* Smith */
if ( i ) {
BEGIN_RING( 2 );
RADEON_WAIT_UNTIL_3D_IDLE();
ADVANCE_RING();
}
radeon_emit_clip_rect( dev_priv, &box );
}
[...]
} while ( ++i < cmdbuf->nbox );
I've still experienced the occasional lockup with multiple cliprects, so
I wonder if we shouldn't simply always do a RADEON_WAIT_UNTIL_3D_IDLE()
in radeon_emit_clip_rect() (which would also take care of older ioctls
with similar loops)?
I also wonder if that isn't the correct fix, i.e. the scissor registers
shouldn't be written to while the 3D engine is busy.
Last but not least, as Keith pointed out a rather long while ago, at
least the R200 engine (but the docs I have suggest this goes back to
Rage128 even) has three more sets of scissor registers, has anyone
played with those yet?
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
