Hi Vincent,

Vincent Favre-Nicolin <fa...@esrf.fr> writes:
>       This is mostly a note in case someone has the same issue.
>
>       I am setting up a debian8 virtual machine, with nvidia drivers from 
> jessie-backports.
>
>       After installing fresh pyopencl using pip, I got an error:
>
> ---> 39 from pyopencl._cffi import ffi as _ffi
>      40 from .compyte.array import f_contiguous_strides, c_contiguous_strides
>      41 
>
> ImportError: 
> /home/pynx/pynx-env/lib/python3.4/site-packages/pyopencl/_cffi.abi3.so: 
> undefined symbol: clSVMFree
>
>
>       After some digging, this is due to the fact that pyopencl was compiled 
> with OpenCL 2.0 support, which the installed libraries do not support.
>
>       And that in turn is due to debian8’s OpenCL headers, which as of 
> version 2.0~svn31815-2~bpo8+1 includes:
> #define CL_VERSION_1_0                              1
> #define CL_VERSION_1_1                              1
> #define CL_VERSION_1_2                              1
> #define CL_VERSION_2_0                              1
>
>       ..and that ‘CL_VERSION_2_0’ triggers the OpenCL 2.0 support in pyopencl…
>
>       The solution is either to not install the opencl-headers from backports 
> (only the nvidia drivers), or to use the 'CL_PRETEND_VERSION’ option (but 
> that requires manual compilation, less convenient than pip for deployment)..
>
>       So, problem solved, but I find this less than satisfying. 
> - Should pyopencl compile with OpenCL 2.0 support even if no OpenCL 2 
> devices/libraries are present (which is the case according to clinfo) ?
> - Does that also mean that on a system with a mixture of 1.2 and 2.0 devices 
> different pyopencl versions would be needed ? 
> - Or is it a bug in debian8 backports with the wrong header ?
> - Or maybe I should blame nvidia for sticking to 1.2 only...

In your case, I would attribute the issue mainly to the fact that you
have an ICD loader (libOpenCL.so) that does not match the installed
headers. If you ended up installing 'nvidia-libopencl1', that's what you
get. Realistically, 'nvidia-libopencl1' should depend on the correct
version of the CL headers (1.2 only) because otherwise those declare
symbols that don't exist--and PyOpenCL has no easy way of finding out.

Fortunately, a 'proper' fix is easy--in particular one that does not
require unnecessarily clamping down PyOpenCL's feature support. Simply
uninstall nvidia-libopencl1 and replace it with
'ocl-icd-opencl-dev'. This exports the CL2 symbols, and PyOpenCL's
compilation will succeed. (independently of whether CL2 devices--or
really *any* devices are available)

If you're in a blaming mood, another party that deserves some blame is
perhaps Nvidia, for shipping an ICD loader that is artificially limited
to OpenCL 1.2. I have a sneaking suspicion that this is deliberate on
their part, so as to backstab the OpenCL developer experience through
a thousand paper cuts. (Note that this is entirely different from
supporting CL 2 on their devices, which requires much more engineering
resources that simply updating the version of the Khronos ICD loader [1]
that they ship.)

[1] https://github.com/KhronosGroup/OpenCL-ICD-Loader

Debian could also simply stop shipping this less-than-helpful ICD loader.

Andreas

PS: If you decide to file some Debian bugs as a result of this, feel
free to cc me.

_______________________________________________
PyOpenCL mailing list
PyOpenCL@tiker.net
https://lists.tiker.net/listinfo/pyopencl

Reply via email to