OpenCL–OpenGL Buffer Sharing: Is clEnqueueAcquireGLObjects Enough for Cross-API Visibility?

Short answer

No—clEnqueueAcquireGLObjects / clEnqueueReleaseGLObjects define ownership, not a complete cross-API memory-visibility contract on every conformant stack. The OpenCL 1.2 specification (cl_khr_gl_sharing) states that prior to acquire, the application must ensure that any pending GL operations affecting the shared objects have completed. In practice, portable code issues glFinish() (or at minimum glFlush() plus a sync wait) before acquire, and treats acquire/release as the ownership transfer rather than the flush mechanism. This is the conservative reading; whether your driver needs it is driver-dependent, which is exactly why you should test rather than assume.

Confirmed facts vs. likely explanation

Confirmed by the spec: the acquire call transfers ownership of the shared object from GL to CL, release transfers it back, and outside the acquire interval the object belongs to GL. The spec also says the application is responsible for ensuring GL work touching the object is complete before acquire. It does not state that acquire itself drains the GL command stream.

Likely explanation for the ambiguity: some ICDs (notably several desktop NVIDIA and AMD drivers) internally flush or synchronize on acquire, so naive code appears to work. Other stacks—particularly some EGL-based or tiled-rendering paths—do not, and you observe stale texture contents in the kernel. Because the spec leaves the flush responsibility with the application, both behaviors are arguably conformant, and the failure mode is silent corruption rather than an error code.

Platform uniformity

The answer is not uniform across WGL, EGL/GLX, and CGL. The context-creation properties differ (CL_GL_CONTEXT_KHR/CL_WGL_HDC_KHR vs. CL_EGL_DISPLAY_KHR vs. the CGL share group property), and the underlying driver paths that couple the GL command stream to the CL device differ with them. EGL in particular spans desktop GL and GLES, where implicit flush behavior is historically less consistent. Assume OpenCL 1.2+ with a recent desktop GL, but verify per platform rather than extrapolating from one vendor.

Minimal correct handoff

// GL side: render into shared texture, then make work visible
glFinish();  // or glFlush + glClientWaitSync on a fence

clEnqueueAcquireGLObjects(queue, 1, &tex_mem, 0, NULL, NULL);
clEnqueueNDRangeKernel(queue, kernel, ...);
clEnqueueReleaseGLObjects(queue, 1, &tex_mem, 0, NULL, NULL);
clFinish(queue);  // before GL re-uses the texture

glFinish is the correctness-safe choice; a fence sync (glFenceSync + glClientWaitSync) reduces the stall if latency matters. On the release side, clFinish (or waiting on the release event) before GL draws again is the symmetric requirement.

Minimal test loop to expose an insufficient driver

1. Create a shared texture via clCreateFromGLTexture.
2. Each frame: render a known, frame-varying pattern (e.g., a solid color encoding the frame index) into it with GL.
3. Without any glFlush/glFinish, immediately acquire, run a kernel that copies the texture to a CL buffer, release, clFinish, and read back.
4. Compare read-back pixels against the expected pattern. Mismatches or one-frame-lag values indicate the driver does not flush on acquire.
5. Repeat with glFinish() before acquire. If results change, the explicit flush is required on that stack.

Run this on at least two vendors and on both WGL and EGL contexts before concluding anything about portability. One missing detail that would change the recommendation: which ICD and OS binding you are targeting—if it is a single known desktop stack, you can empirically drop the glFinish only after the test above passes consistently.