I have some news.

The Nvidia gurus replied to my question:

In fact in my C-code there was an issue: when using the "clCreateContext" function I was not counting the number of available devices correctly on my Linux machine.
Therefore the graphics driver was throwing an error. This has been now fixed on my C-code by following their suggestion.

Considering all this, I am still unable to run the Pyopencl example "gl_interop_demo.py" as is on my Linux machine (it crashes with segmentation fault, as per the original question on this thread in this mailing list).

The fact that now, in C, everything is working as expected leads me to think there is a problem within Pyopencl, or at least with the "gl_interop_demo.py". One other important thing to remember is that I experience crashes in Pyopencl only when I try to create a shared CL-GL interop context. Is it possible that, maybe, the problem is connected to the interop in Pyopencl?

Best regards

Erik Zorzin
address: Viale Miramare 235, 34136 Trieste - ITALY
phone: (+39) 3291555703
webpage: http://www.zorzin.com

(sent from my MacBook Air, Erik Zorzin - HOME)

On Tue06 Mar 2018 at 21:43:16, Andreas Kloeckner (lists@informa.tiker.net) wrote:

Erik Zorzin - HOME <erik@zorzin.com> writes:

> Not yet, but I can do it as you suggest.
> However, I believed that Pyopencl, somewhere buried into some C-wrappers, should be able to make a correct use of the clCreateContextFromType the way I am using it in C (which is working for me in Linux) when invoking it from Python like this:
> ...
> platform = cl.get_platforms()
> context =   cl.Context(dev_type = cl.device_type.GPU,
>                                    properties = [(cl.context_properties.PLATFORM,
>                                    platform[0])] + get_gl_sharing_context_properties())
> ...
> but this crashes on Linux with the same segmentation fault.
> I tried to reverse-engineer a bit your code: in "cffi_cl.py", for the class Context, I found this code fragment:
> ...
> if devices is not None:
>             # from device list
>             if dev_type is not None:
>                 raise RuntimeError("one of 'devices' or 'dev_type' "
>                                    "must be None",
>                                    status_code.INVALID_VALUE, "Context")
>             _devices, num_devices = _clobj_list(devices)
>             # TODO parameter order? (for clobj_list)
>             _handle_error(_lib.create_context(_ctx, c_props,
>                                               num_devices, _devices))
>         else:
>             # from device type
>             if dev_type is None:
>                 dev_type = device_type.DEFAULT
>             _handle_error(_lib.create_context_from_type(_ctx, c_props,
>                                                         dev_type))
> ...
> as far as I can understand, when invoking the Context class by passing the "dev_type" parameter = "cl.device_type.GPU" this should select the "else" case, hence the wrapper "create_context_from_type" which I found defined in "context.cpp":
> ...
> create_context_from_type(clobj_t *_ctx, const cl_context_properties *props,
>                          cl_device_type dev_type)
> {
>     // TODO debug print properties
>     return c_handle_error([&] {
>             *_ctx = new context(
>                 pyopencl_call_guarded(
>                     clCreateContextFromType,
>                     const_cast<cl_context_properties*>(props),
>                     dev_type, nullptr, nullptr), false);
>         });
> }
> ...
> Do you think there is any possibility that the latter "pyopencl_call_guarded(clCreateContextFromType, ..etc..)" wrapper in not doing what it is supposed to do? I mean, is it possible that function is not building the correct "clCreateContextFromType" C-function with all necessary arguments?
> I am speculating this because, in my C test program, the clCreateContextFromType function works fine in both Linux and Mac.
> I agree with you it is still not clear why the simple clCreateContext in C apparently does not work in Linux (at least on my computer).

Thanks for investigating! Given the amount of shared code (with
clCreateContext) and compiler type checking present, I'd say it'd be
hard for the clCreateContextFromType wrapper to be wrong. But I did
notice that the function is untested, and I'd be happy to merge a patch
that adds a test.