Exclusive access semantics of clEnqueueAcquireGLObjects for shared OpenGL textures

Direct answer

No. The OpenCL 1.2 specification does not require clEnqueueAcquireGLObjects to block OpenGL commands or lock the shared texture. Acquiring an object transfers synchronization responsibility to the application; it does not create a driver-enforced mutex.

What the specification guarantees

Confirmed by the spec: the acquire/release pair exists so the application can tell each API when the other may safely touch the object. The spec explicitly categorizes concurrent GL and CL access to the same shared object as undefined behavior. It does not mandate that the driver stall, serialize, or reject GL calls while an object is acquired.

What implementations may do

Likely but not guaranteed: some GPU drivers implicitly serialize access, making races rare in simple demos. Other drivers allow overlapping execution, so a GL write issued after an acquire can corrupt data or crash. Because the spec leaves enforcement to the implementation, code that relies on implicit blocking is non-portable across NVIDIA, AMD, and Intel.

Required application-level synchronization

1. Before calling clEnqueueAcquireGLObjects, ensure all prior GL commands that touch the texture have completed. Use glFinish() or, preferably, glFenceSync() followed by glClientWaitSync().
2. Do not issue any GL command that reads or writes the texture between the acquire and the matching clEnqueueReleaseGLObjects.
3. After the release completes on the CL side, the texture is again available for GL use.

Threading caveat

If GL and CL are driven from separate host threads, the above fences are insufficient. Add host-side synchronization (for example, a mutex or condition variable) around the acquire/release window so one thread cannot enqueue GL work while another holds the CL acquisition.

Verification

To confirm the lack of implicit blocking on your target driver, insert a glTexSubImage2D write immediately after clEnqueueAcquireGLObjects without a preceding GL fence, then run under a debug context or vendor profiling tool. If corruption or a GPU fault appears, the driver is not serializing access. Repeating the test with glFenceSync + glClientWaitSync before the acquire should eliminate the fault.

One diagnostic detail changes the recommendation: are your GL and CL contexts driven from the same host thread? If yes, the GL fence alone is the required fix. If no, host-side locking is also mandatory.