On Mon, 2006-06-26 at 22:40 +0200, Martijn van Oosterhout wrote: > On 6/26/06, Keith Whitwell <[EMAIL PROTECTED]> wrote: > > The semantics are that it is valid between LOCK_HARDWARE() and > > UNLOCK_HARDWARE(). On a lower level, you've investigated the way it is > > updated on contended locks already. > > I see. In any case I've found one problem, and that is with the code > in r128UpdateClipping: > > x1 += drawable->x; > y1 += drawable->y; > x2 += drawable->x; > y2 += drawable->y; > > rmesa->setup.sc_top_left_c = ((y1 << 16) | x1); > rmesa->setup.sc_bottom_right_c = ((y2 << 16) | x2); > > Nowhere is there any protection for negative values. If either of x1 > or x2 are negative (drawable hangs off left hand side of screen), they > blat the corresponding y value. By clamping them to my screen > dimensions the problem has markedly reduced and in some cases no > longer exists (it no longer wraps around the left of the screen, only > the right now). So I think I'm on the right track here.
Yes, please post a diff so we might get an idea what's missing still. One thing to keep in mind is that [xy]2 must be the coordinates of the rightmost column / bottommost line, not the ones immediately outside. > > One common problem is where the cliprect information is used to build > > commands in DMA buffers - if this happens it is necessary to fire that > > dma before releasing the DRI lock, otherwise the contents of the buffer > > will potentially be incorrect. > > Yeah, that may be the issue. However, the DRM kernel module uses > cliprects stored elsewhere, in the sarea. However, I never see these > configured at all, which seems odd. See r128FlushVerticesLocked(), e.g. > The thing most confusing me is that with all these possible bugs, how > is it that it works at all most of the time. If I put simple 3d apps > half off screen there's no problem. It must be the shear volume of > data being transferred that's confusing it. That's unlikely. > For example, in the case I showed, r128GetLock is only ever called if > I resize the window or move something. I would have thought it would be > called more often than that... That's not too surprising, if you look at LOCK_HARDWARE(), it only calls r128GetLock() if the HW lock was taken by another context since the last time this context had it (as the drawable information can only have changed in that case). The X server should take the lock every time it processes any request though... -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer 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
