Segfault in clCreateFromGLBuffer on Arch64/Intel HD 5500/Beignet

[seanlynch]

I'm trying to figure out how to share buffers between OpenCL and OpenGL, so I wrote a minimal test program just to make sure it worked. After recompiling PyOpenCL from git with --cl-enable-gl, pyopencl.has_gl() returns True, but the following program gives me a segfault at line 61. I've tried calling glFlush() in case it was a synchronization problem, but that did not help.

https://gist.github.com/seanlynch/f85846283fc712fd91ad

Stack trace:

#0  0x0000000000000000 in ?? ()
#1  0x00007f8ed0ee9e91 in clCreateFromGLBuffer () from /usr/lib/libOpenCL.so.1
#2  0x00007f8ed1140507 in create_from_gl_buffer ()
   from /home/seanl/project/voxel/pyenv/lib/python3.5/site-packages/pyopencl-2015.2.4-py3.5-linux-x86_
64.egg/pyopencl/_cffi.cpython-35m-x86_64-linux-gnu.so                                                
#3  0x00007f8ed1117fb6 in _cffi_f_create_from_gl_buffer(_object*, _object*) ()
   from /home/seanl/project/voxel/pyenv/lib/python3.5/site-packages/pyopencl-2015.2.4-py3.5-linux-x86_
64.egg/pyopencl/_cffi.cpython-35m-x86_64-linux-gnu.so                                                
#4  0x00007f8edbee05e9 in PyCFunction_Call () from /usr/lib/libpython3.5m.so.1.0
#5  0x00007f8edbf585f1 in PyEval_EvalFrameEx () from /usr/lib/libpython3.5m.so.1.0
#6  0x00007f8edbf599e2 in ?? () from /usr/lib/libpython3.5m.so.1.0
#7  0x00007f8edbf59ac3 in PyEval_EvalCodeEx () from /usr/lib/libpython3.5m.so.1.0
#8  0x00007f8edbec3b98 in ?? () from /usr/lib/libpython3.5m.so.1.0
#9  0x00007f8edbe990da in PyObject_Call () from /usr/lib/libpython3.5m.so.1.0
#10 0x00007f8edbeafd64 in ?? () from /usr/lib/libpython3.5m.so.1.0
#11 0x00007f8edbe990da in PyObject_Call () from /usr/lib/libpython3.5m.so.1.0
#12 0x00007f8edbef5a10 in ?? () from /usr/lib/libpython3.5m.so.1.0
#13 0x00007f8edbef3de6 in ?? () from /usr/lib/libpython3.5m.so.1.0
#14 0x00007f8edbe990da in PyObject_Call () from /usr/lib/libpython3.5m.so.1.0
#15 0x00007f8edbf524bc in PyEval_EvalFrameEx () from /usr/lib/libpython3.5m.so.1.0
#16 0x00007f8edbf58942 in PyEval_EvalFrameEx () from /usr/lib/libpython3.5m.so.1.0
#17 0x00007f8edbf599e2 in ?? () from /usr/lib/libpython3.5m.so.1.0
#18 0x00007f8edbf59ac3 in PyEval_EvalCodeEx () from /usr/lib/libpython3.5m.so.1.0
#19 0x00007f8edbf59aeb in PyEval_EvalCode () from /usr/lib/libpython3.5m.so.1.0
#20 0x00007f8edbf78c64 in ?? () from /usr/lib/libpython3.5m.so.1.0
#21 0x00007f8edbf7b175 in PyRun_FileExFlags () from /usr/lib/libpython3.5m.so.1.0
#22 0x00007f8edbf7b2e6 in PyRun_SimpleFileExFlags () from /usr/lib/libpython3.5m.so.1.0
#23 0x00007f8edbf920f4 in Py_Main () from /usr/lib/libpython3.5m.so.1.0
#24 0x0000000000400af7 in main ()
(gdb) frame 3
#3  0x00007f8ed1117fb6 in _cffi_f_create_from_gl_buffer(_object*, _object*) ()
   from /home/seanl/project/voxel/pyenv/lib/python3.5/site-packages/pyopencl-2015.2.4-py3.5-linux-x86_
64.egg/pyopencl/_cffi.cpython-35m-x86_64-linux-gnu.so 

Output of clinfo: https://gist.github.com/seanlynch/4c8b20c916fbab3c694b

Thanks for any help you can give me.

[inducer]

I don't think beignet has GL interop just yet:

https://cgit.freedesktop.org/cgit/?url=beignet/tree/docs/Beignet.mdwn#n204

[seanlynch]

Ah, didn't think to check since I wouldn't have expected a segfault for an unsupported API. I'm guessing that's ocl-icd's fault.

Thanks!

[seanlynch]

Looks like it is indeed ocl-icd's fault, since if I use beignet's libcl directly, I get:

seanl@michiru ~/project/voxel (git)-[master] % python noisetest.py                                     
Traceback (most recent call last):
  File "noisetest.py", line 8, in <module>
    import pyopencl as cl
  File "/home/seanl/project/voxel/pyenv/lib/python3.5/site-packages/pyopencl-2015.2.4-py3.5-linux-x86_64.egg/pyopencl/__init__.py", line 35, in <module>
    import pyopencl.cffi_cl as _cl
  File "/home/seanl/project/voxel/pyenv/lib/python3.5/site-packages/pyopencl-2015.2.4-py3.5-linux-x86_64.egg/pyopencl/cffi_cl.py", line 36, in <module>
    from pyopencl._cffi import ffi as _ffi
ImportError: /home/seanl/project/voxel/pyenv/lib/python3.5/site-packages/pyopencl-2015.2.4-py3.5-linux-x86_64.egg/pyopencl/_cffi.cpython-35m-x86_64-linux-gnu.so: symbol clCreateFromGLRenderbuffer, version OPENCL_1.0 not defined in file libOpenCL.so.1 with link time reference

which makes the problem a lot more clear.

[seanlynch]

Ok, so Beignet does claim to implement clCreateFromGLTexture, but even though pyopencl.GLTexture is listed in the documentation, I see that in the code it just raises a NotImplementedError. So Beignet doesn't implement clCreateFromGLBuffer and pyopencl doesn't support clCreateFromGLTexture. Do you know what needs to be done to make pyopencl.GLTexture work?

[vdanjean]

Hi,
I'm ocl-icd upstream.
From my point of view, the clCreateFromGLRenderbuffer function must be provided by ocl-icd as it must be available to programs using ICD (ie OpenCL implementation) that implement it. Note that ocl-icd loads ICD at run-time, so this symbol cannot disappear if the ICD do not provide it.
That said, this function is a bit special as implementation are not required to implement it. However, it is the responsibility to the user to check its availability before using (calling) it.
From the documentation (https://www.khronos.org/registry/cl/sdk/2.1/docs/man/xhtml/clCreateFromGLRenderbuffer.html) :

If this extension is supported by an implementation, the string "cl_khr_gl_sharing" will be present in the CL_DEVICE_EXTENSIONS string described in the table of allowed values for param_name for clGetDeviceInfo or in the CL_PLATFORM_EXTENSIONS string described in the table of allowed values for param_name for clGetPlatformInfo.

@seanlynch : you say that Beignet does claim to implement clCreateFromGLTexture. Are you sure that cl_khr_gl_sharing is shown by Beignet? (I did not check) Because the availability of the symbol is not the good way to check the availability.

So, from my point of view, users must correctly check the OpenCL functions they use (when they are not always available). There is the same kind of problems when functions from OpenCL 2.x are called with ICD supporting only OpenCL 1.x. Users (or run-times if they want to provide version agnostic support) must check the ICD version before calling version specific functions.

[seanlynch]

I meant Beignet's documentation claims it:

We lack of some APIs implementation such as clCreateFromGLBuffer,clCreateFromGLRenderbuffer,clGetGLObjectInfo... Currently, the working APIs are clCreateFromGLTexture,clCreateFromGLTexture2D. We may need to find a graceful way to co-work with mesa.

It's quite possible that I was misreading what that meant. A developer has confirmed that Beignet does not in fact support clCreateFromGLTexture, and looking at the source code confirms that it is indeed not supported. It also looks like there's going to be a substantial amount of work involved since there needs to be support from the Mesa side because for some reason Intel has chosen to do their work outside of Mesa.

At this point I'm trying to see if there's some undefined behavior that will let me share buffers/textures/images "by accident" (I have no idea how realistic that is but this slide deck gives me some hope) until Beignet gets support for cl_khr_gl_sharing. Otherwise I guess I'll just switch to GLSL. Perhaps I can do something similar to Reikna and generate both GLSL and OpenCL from the same templates.

[seanlynch]

Actually I just discovered a decent fallback which should be fine on an integrated device since AFAICT it involves only a single copy that doesn't go over the PCI bus. Method 3 in https://software.intel.com/en-us/articles/opencl-and-opengl-interoperability-tutorial involves glMapBuffer, clCreateBuffer with CL_MEM_USE_HOST_PTR, clEnqueueMapBuffer, run kernel, clEnqueueUnmapMemObject, glUnmapBuffer, and glTexSubImage2D.

I'll try this out tonight (California time) and see if it's a reasonable fallback until Beignet gets cl_khr_gl_sharing support.