I figured out the issue. As I thought, it is a bug in the context creation of pyopencl. Essentially properties that are passed to cl.Context() as pointer types are handled incorrectly. The code takes the address of the pointer type instead of getting the address it points to; ergo, the context is invalid and causes segfaults when the underlying OpenCL runtime tries to interpret it.
After the following modifications within cffi_cl.py, the example interop code provided with pyopencl runs and displays the particle fountain: def _parse_context_properties(properties): ... from ctypes import _Pointer, addressof from ctypes import cast # add this if isinstance(value, _Pointer): #val = addressof(value) # remove this val = cast(value, ctypes.c_void_p).value # add this else: val = int(value) -- Aaron Myles Landwehr On Wed, Apr 12, 2017 at 7:43 PM, Aaron Myles Landwehr <a...@udel.edu> wrote: > Yeah it does, I also checked before my initial email to make sure some of > the other libraries NV provided matched the driver also to make sure > generic or MESA ones weren't being loaded instead. > > [ 3.223978] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 375.51 Wed > Mar 22 10:26:12 PDT 2017 (using threaded interrupts) > > -- > Aaron > > On Wed, Apr 12, 2017 at 7:24 PM, Andreas Kloeckner < > li...@informa.tiker.net> wrote: > >> Aaron Myles Landwehr <a...@udel.edu> writes: >> >> > Good catch, didn't think to check. It's also worth noting that I was >> using >> > an older revision of the NV drivers before (with the same issue) and >> > switched to this revision to see if it would resolve the issue. >> > >> > [15710.755225] python[12352]: segfault at c4fe8 ip 00007fef36394522 sp >> > 00007fef319c3740 error 6 in libnvidia-glcore.so.375.51[7fe >> f352fe000+13e4000] >> >> Hmm--does your GL driver match the kernel-side component, in terms of >> version? >> >> dmesg |grep NV >> >> Andreas >> > >
_______________________________________________ PyOpenCL mailing list PyOpenCL@tiker.net https://lists.tiker.net/listinfo/pyopencl