Hi Evan, thanks for adding this information.
Knowing this, should we consider my issue to be closed as "unsolvable"? Is there any possibility of further investigation? My opinion is that there should be something wrong in Pyopencl, either a problem in the "gl_interop_demo.py" or in the Pyopencl core: otherwise how would you explain the fact my C test code always works on the same machines + same drivers where Pyopencl fails? 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 Thu08 Mar 2018 at 19:32:04, Evan Sims (w...@msn.com) wrote: http://pyopencl.tiker.narkive.com/Kq2NgLWF/unanble-to-run-either-gl-interop-examples-invalid-context-no-attribute-buffer This is probably of no value since I couldn't figure this out and sort of gave up. It is perhaps related though so I thought I would point it out. I also could not get interop working, but with AMD. I believed it was due to PyOpenGL and the changes in its context creation. There was supposedly a fix for it though. I could fiddle with the buffers and I could get the particles to display instead of an immediate segmentation fault, but I only have very limited troubleshooting abilities and was not able to solve this issue. -Evan From: PyOpenCL <pyopencl-boun...@tiker.net> on behalf of Erik Zorzin - HOME <e...@zorzin.com> Sent: Thursday, March 8, 2018 12:10 AM To: pyopencl@tiker.net; Andreas Kloeckner Subject: Re: [PyOpenCL] Pyopencl gl interop segmentation fault - Nvidia. Hi, I have some news. The Nvidia gurus replied to my question: https://devtalk.nvidia.com/default/topic/1030737/?comment=5243849 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 (li...@informa.tiker.net) wrote: Erik Zorzin - HOME <e...@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. Andreas
_______________________________________________ PyOpenCL mailing list PyOpenCL@tiker.net https://lists.tiker.net/listinfo/pyopencl
