Tim Smith wrote: > 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.
Gareth tried to get this working in the initial driver, but didn't get it to be reliable. I've got an older card here so I can test a patch against that. On the contents of your patch: Is it necessary to put this wait in emit_clip_rect? Where is the 2d activity you're waiting for coming from? Is it the X server, or the Clear or Swapbuffers ioctls? It would be good to narrow it down & only do the wait where necessary... > 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 :-) Yes, there's no question that banging on the bus like that was dumb. It's good to see it may not be necessary after all... Keith ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
