I found a few other ways of provoking the problem while I was at it, and
dragging an xclock window over the 3D view did it too (with a window
manager and "solidmove" turned on). In fact, I also managed to provoke the
lockup by persistently dragging xclock around over a maximised glxgears in
1600x1200 but it took a lot of mouse waggling.
The fix turns out to be very simple of course:
--- radeon_state.c 27 Jun 2002 17:56:39 -0000 1.17
+++ radeon_state.c 29 Jun 2002 14:52:20 -0000
@@ -48,7 +48,8 @@ static inline void radeon_emit_clip_rect
DRM_DEBUG( " box: x1=%d y1=%d x2=%d y2=%d\n",
box->x1, box->y1, box->x2, box->y2 );
- BEGIN_RING( 4 );
+ BEGIN_RING( 6 );
+ RADEON_WAIT_UNTIL_2D_IDLE();
OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
OUT_RING( (box->y1 << 16) | box->x1 );
OUT_RING( CP_PACKET0( RADEON_RE_WIDTH_HEIGHT, 0 ) );
In the course of poking around, I enabled the code that causes the scratch
registers to be written out to memory by the card when they are updated,
and extended the getparam ioctl so that user space could obtain them with a
quick ioctl rather than doing MMIO. This has made things run quite a bit
smoother[1] since it no longer has to hammer the bus to get the value
(though it didn't fix the problem; I was wondering whether or not reading
the registers by MMIO would muck with the command FIFO behind the CCE
microengine's back, but apparently not). Is there some other reason why
this is a bad idea or should I prepare a patch? BTW the radeonClear()
throttling doesn't call delay(), so that loop will get optimised out.
In a totally unrelated note, the texture funnies that I reported earlier do
not occur in 24-bit mode, but only in 16-bit mode. Tux Racer shows this too
though in tux racer the problem is still visible in 16bit mode though less
blatant.
[1] I now have to zoom out to view nearly the entire area before it turns
into a slideshow, which is about 3x more on screen than before. FWIW, I
*expect* it to turn into a slideshow at that point with this app; zooming
out that far is possible, but not exactly recommended :-)
--
Tim Smith ([EMAIL PROTECTED])
The difference between theory and practice is that, in theory, there *is*
no difference between theory and practice.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
