On Sat, 2003-04-12 at 10:17, Leif Delgass wrote: > I think setting rmesa->sarea->nbox = 0 when there are 3 or fewer cliprects > and the cliprects dirty flag isn't set should be correct. The idea is > that, since r128 has three auxiliary hardware scissors (3 cliprects can be > emitted per re-used vertex buffer), there is no need to update the scissor > registers unless the cliprects have changed or there are more than 3 > cliprects. Actually, I'm not sure why the test isn't nbox < 4.
Similarly the check for nbox >= R128_NR_SAREA_CLIPRECTS should be a > right? Wouldn't it make much more sense for the kernel to be basing its uploading of cliprects off of sarea_priv->dirty & R128_UPLOAD_CLIPRECTS? If I understand it right, then we wouldn't need tricks like count=0 (not 100% sure on this one) and nbox=0 setting. As it is, nothing uses sarea_priv->dirty & R128_UPLOAD_CLIPRECTS. > The real problem may be elsewhere. One possibility is that on context > switches with the X server, the ring may not be flushed of drawing > commands using old clipping information. Another thing that might help is > updating the window position and scissor information immediately from > r128GetLock, rather than setting new_state flags. This is one of the > changes I made in the mach64 driver relative to r128, based on the code in > the radeon driver. > > Mach64 used to have the same sort of clipping and overlapping window > problems as r128. I'll have to go back through my changes and see if I > can reconstruct what I did. > > It would also improve window moving if we implement XAA blits for > back-buffer (and depth buffer?) moves as in the Radeon driver (I did this > for mach64 also). For now it's still an improvement because it does clip things correctly, but by uploading cliprects every time. I'll try to compare more carefully against what radeon/mach64 do with clipping and get it fixed right. I don't think XAA blits would solve the problem I was seeing, if you were trying to say that. Once in a while after moving the window the gears would continue spinning at the same offset in the screen as before, just with the window in a different place. I'll take a look at that, though. Another question: the advantage of Allocate/FreeOffscreenArea()s in the TransitionTo2/3d is to leave more room for pixmaps in the 2d-only case, right? -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
