Martijn van Oosterhout wrote: > As suggested earlier I've instrumented r128GetLock() so it prints out > the ClipRects as they change. Turns out in dri_utils there's also a > function that updates the ClipRects. Anyway, there must be something > else changing it also, but I can't work out where... > > r128GetLock: Cliprect change (copy dPriv to rmesa): > Old: (0xno stamp) [(477,238)-(1024,748)] (ptr=0x8aee3a0) > New: (0xb3c56080) [(961,238)-(1024,748)] (ptr=0x8b75060) > __driUtilUpdateDrawableInfo: Cliprect change: > Old: (0xb3c56080) [(961,238)-(1024,748)] > New: (0xb3c56080) [(961,238)-(1024,748)] > r128GetLock: Cliprect change (copy dPriv to rmesa): > Old: (0xno stamp) [(477,238)-(1024,748)] (ptr=0x8b75060) > New: (0xb3c56080) [(961,238)-(1024,748)] (ptr=0x8aee3a0) > > As you can see, in the second GetLock, the cliprects pointed (address > 0x8b75060) to have been overwritten with incorrect values. The > GetDrawableInfo function has it correct. The 477 is the starting point > of the actual drawable, however, another window is obscuring > everything up to 961. I'm at a loss to explain the chaged values, is > it likely to be overwritten by the xserver maybe? Also, the > pdp->pStamp never seems to change, I'm not sure if this is normal. > > I enabled SWRAST_DEBUG and saw that it's not using the software > renderer. Nor is any fallback active. Since the DRM driver uploads the > cliprects to the card before every vertex command, if someone changed > the memory pointed by dPriv->pClipRects to during rendering, that > might cause the problem I'm chasing. > > What are the semantics for dPriv->pClipRects? When is it allowed to be > changed, how long is it valid for and who changes it? > > Thanks in advance,
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. 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. Your problem with changing cliprect values seems to be unrelated to the above, though. Keith 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
