Yup, using driver version 95.39 and Beta SDK 3.0, on Windows XP, I was able to use GL interoperability fine (I’ve tested it on 6800, 8800, and GTX285). Though I only used shared VBOs and Images, not render buffers.
Additionally I always created the CL object immediately after the GL object, before I actually use it in a kernel or a GL operation. I noticed once an texture/image had been used by GL I could not access the bits via the CL C API, only via the GL glGetTexImage API.
Another gotcha I noticed is the event argument to the Aquire/Release functions is never filled in by them.
Well if it is shared, you’d expect either API to work.
I don’t think its anything to do with your problem. But if you pass an event pointer into clEnqueueAcquireGLObjects or clEnqueueReleaseGLObjects then it is ignored (and if you try release or wait on the value you passed in your get an error, as it will be uninitialized).
Though is CL_MEM_READ_ONLY the access right flag ? Even if your CL kernel only reads from it, the GL code is writing to it (which presumably amounts to the same thing under the hood), shouldn’t t be read+write ?