:D:P

Well it's not like I have a choice XP.

Get Windows 8.x now!!!! It'll be the cheapest way to get Win10. Honestly, it's well worth it. 8.x is a great OS, 10 will be even better.

1. Link against the stub library (static library )..provided by the implementation.

And not even that is strictly necessary. Back when I considered OpenCL (which thanks to lack of GL/CL synchronization functionality turns out being pretty useless), I simply used LoadLibrary("opencl32.dll") and did a couple of GetProcAddress calls after having my WTF time with these weird vendor APIs that seem to do nothing and don't seem to work no matter what you try.

Turned out there was some almost-working source for a fully dynamic loader (CL 1.0 only) freely available from some Apple-related guy on the internet, you can tweak that one to work on Windows and upgrade to 1.1 (and presumably 1.2 too, I didn't try) in under half an hour.

So, except for the one important detail that it sucks because you can't properly synchronize GL and CL, it works just fine.

Doesn't clEnqueueAcquireGLObjects/clEnqueueReleaseGLObjects do just that? I haven't had any problems with it personally though I've seen people say CL/GL interop was inefficient with some driver versions.

That would be nice. Unluckily, as far as I can tell, that is not the case. The spec says:

Prior to calling clEnqueueAcquireGLObjects, the application must ensure that any pending GL operations which access the objects specified in mem_objects

have completed. This may be accomplished portably by issuing and waiting for completion of a glFinish command on all GL contexts with pending references to these objects. Implementations may offer more efficient synchronization methods [...] sometimes glFlush may be sufficient

[...] modifies the behavior of clEnqueueAcquireGLObjects and clEnqueueReleaseGLObjects to implicitly guarantee synchronization with an OpenGL context

bound in the same thread as the OpenCL context.

Unluckily, this is supported... nowhere.