Broken OpenGL/OpenCL interoperability support

[bobbyblues]

After a recent update, I cannot use OpenGL/OpenCL interoperability, though it had been working for about 2 years with no issue.

Note that OpenGL by itself still runs well on the Nvidia card, so does OpenCL, but as soon as I try to share data between the two, I get the following error message:

Xlib: extension "NV-GLX" missing on display ":0.0".

I'm not sure if a recent change in bumblebee is responsible for this, or if I need to reconfigure something. From what I get, the error is raised as soon as I use the "enqueueAcquireGLObjects" function from OpenCL.

I understand that the nvidia card actually runs on the display :8 by default, one workaround might be to tell OpenCL to run on this display as well, but I can't find how to do so.

[illuhad]

Any news on this? I have the same problem regarding OpenCL sharing, same error message. Sharing CUDA<->OpenGL works, so I assume my system configuration is correct. I use Arch Linux, with nvidia driver 370.28-1.

[s-ol]

Still experiencing the same issue, also on ArchLinux:

linux 4.18.14.arch1-1
nvidia 410.57-6
bumblebee 3.2.1-20
primus 20151110-7

[s-ol]

I can prevent my program from crashing by exporting DISPLAY=:8, but then I cannot see it's output.

This happens regardless of whether I set DISPLAY outside or inside primusrun:

env DISPLAY=:8 primusrun ...
primusrun env DISPLAY=:8 ...

[dcommander]

A customer reported a similar issue to me in the context of using a commercial OpenGL application with VirtualGL and TurboVNC. I was able to reproduce the issue with the OpenCL Marching Cubes Isosurfaces example from https://developer.nvidia.com/opencl. I don't know if you're experiencing exactly the same symptoms, but in our case, the crash occurs within the body of clEnqueueReleaseGLObjects() and is more specifically triggered by a call to glCreateSyncFromCLeventARB() followed by a call to glWaitSync() (the crash actually occurs within the body of glWaitSync(), which appears to be the point at which the nVidia proprietary driver stack is trying to use the non-existent NV-GLX extension.) NV-GLX is proprietary and undocumented, so there is no way to emulate it using an interposer such as VirtualGL or an X proxy such as TurboVNC. I am attempting to find someone at nVidia who can shed light on exactly what their OpenCL/OpenGL interop functions are doing and how I might be able to redirect the NV-GLX requests to the GPU-attached display. Presumably, if I figure anything out there, Bumblebee could take advantage of it as well.