On 12 Apr 2003, Eric Anholt wrote: > 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?
That sounds right, yes. > 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. Yeah, it's all done client side right now. > > 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'm working on this now. I think one of the problems is the delayed updating of new drawable info. The new_state flag isn't examined between acquiring the lock and calling r128FlushVerticesLocked, so new drawable info coming after acquiring the lock doesn't get used until after the vertex buffer is sent, causing stale scissor and window position info to be used. Basically, I'm making the code look a bit more like radeon and mach64. > 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. It wouldn't fix drawing outside of the window, but it would prevent an offset back buffer being swapped to the front or being drawn over and then swapped. That makes the moves look jerky. I think what you're seeing is probably a result of the window offset not being picked up early enough, as I mentioned above. I just tested a patch that reworks the state handling for window position, cliprects and scissor and I've been able to eliminate the "show through" with overlapping windows while still using sarea->nbox = 0 for fewer than 4 cliprects. I'll post a patch you can try soon. > 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? Right, I think we should add this as well. It's especially helpful for these older cards with less memory. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- 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
