This would cause LOCK_HARDWARE to mutex all contexts in this process on
both DRI1 and DRI2. On DRI1, LOCK_HARDWARE already does it for all
processes on the system. On DRI2, LOCK_HARDWARE doesn't, but there shouldn't
be any state outside the context that needs any additional protection.
Notably, the bufmgr is protected by its own mutex and not
LOCK_HARDWARE.
This code was originally introduced with the i915tex code dump, so it's not
clear what it was there for.
}
-_glthread_DECLARE_STATIC_MUTEX(lockMutex);
-
/* Lock the hardware and validate our state.
*/
void LOCK_HARDWARE( struct intel_context *intel )
if (intel->locked >= 2)
return;
- _glthread_LOCK_MUTEX(lockMutex);
-
if (intel->driDrawable) {
intel_fb = intel->driDrawable->driverPrivate;
if (!sPriv->dri2.enabled)
DRM_UNLOCK(intel->driFd, intel->driHwLock, intel->hHWContext);
- _glthread_UNLOCK_MUTEX(lockMutex);
-
if (INTEL_DEBUG & DEBUG_LOCK)
_mesa_printf("%s - unlocked\n", __progname);