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
