On 6/27/06, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> > See r128FlushVerticesLocked(), e.g.
>
> The thing is there's this optimisation that avoid loading the
> cliprects everytime if there are less than three. However, that relies
> on people notifying eachother when they've changed.
And we have a winner! If I remove the optimisation that avoids
uploading the cliprects everytime, the problem vanishes, completely.
So the hardware cliprects are being blatted and my guess is that it's
the Xserver doing it, given it's the only other thing accessing the
hardware, and it doesn't do it via the DRM driver.
The question is, how to fix it. I've downloaded the source for
xserver-xorg-video-ati but the only time it ever seems to do any
locking is changing screen modes.
Where else in the xserver is the DRI locking dealt with? Is it just a
matter of having the Xserver do a DRILock()/DRIUnlock() everytime it
blats the hardware cliprects? However, the Xserver doesn't fiddle the
aux clip rects, only the primary, which should be correctly restored.
OTOH, this code seems very suspicious:
info->sc_right = INREG(R128_SC_RIGHT);
info->sc_top = INREG(R128_SC_TOP);
info->sc_bottom = INREG(R128_SC_BOTTOM);
info->aux_sc_cntl = INREG(R128_SC_BOTTOM);
Shouldn't that last one be R128_AUX_SC_CNTL? Maybe it restores the wrong value?
Many oddities here, that's for sure.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
