Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-14 Thread Andreas Kloeckner
Aaron Myles Landwehr  writes:

> 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)

Thanks for investigating and finding a fix. Now in master:

https://github.com/pyopencl/pyopencl/commit/21008183734b9d13ae2c40ea2e3bdec20ac70250

It'd be great if you could try that and let me know if it works.

Andreas

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


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-13 Thread Aaron Myles Landwehr
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  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  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 7fef36394522 sp
>> > 7fef319c3740 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


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Aaron Myles Landwehr
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 
wrote:

> Aaron Myles Landwehr  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 7fef36394522 sp
> > 7fef319c3740 error 6 in libnvidia-glcore.so.375.51[
> 7fef352fe000+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


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Andreas Kloeckner
Aaron Myles Landwehr  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 7fef36394522 sp
> 7fef319c3740 error 6 in libnvidia-glcore.so.375.51[7fef352fe000+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


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Aaron Myles Landwehr
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 7fef36394522 sp
7fef319c3740 error 6 in libnvidia-glcore.so.375.51[7fef352fe000+13e4000]


--
Aaron

On Wed, Apr 12, 2017 at 7:07 PM, Andreas Kloeckner 
wrote:

> Aaron Myles Landwehr  writes:
>
> > I'm only running as root for testing purposes instead of manually
> entering
> > information for the xauth allow list. I've been doing it for quite some
> > time, and it's always worked fine with native OpenCL/OpenGL interop as
> well
> > as with pycuda's interop so I don't think it's the issue.
> >
> > Just to confirm though, I went ahead and tested with non-root and the
> only
> > difference is that it indicates that a segmentation fault occurs during
> the
> > cl calls:
> >
> >> DISPLAY=:0 python gl_particle_animation.py
> > 
> > Xlib:  extension "NV-GLX" missing on display "P".
> > zsh: segmentation fault (core dumped)  DISPLAY=:0 python
> > gl_particle_animation.py
>
> Anything incriminating in dmesg?
>
> Andreas
>
___
PyOpenCL mailing list
PyOpenCL@tiker.net
https://lists.tiker.net/listinfo/pyopencl


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Andreas Kloeckner
Aaron Myles Landwehr  writes:

> I'm only running as root for testing purposes instead of manually entering
> information for the xauth allow list. I've been doing it for quite some
> time, and it's always worked fine with native OpenCL/OpenGL interop as well
> as with pycuda's interop so I don't think it's the issue.
>
> Just to confirm though, I went ahead and tested with non-root and the only
> difference is that it indicates that a segmentation fault occurs during the
> cl calls:
>
>> DISPLAY=:0 python gl_particle_animation.py
> 
> Xlib:  extension "NV-GLX" missing on display "P".
> zsh: segmentation fault (core dumped)  DISPLAY=:0 python
> gl_particle_animation.py

Anything incriminating in dmesg?

Andreas

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


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Aaron Myles Landwehr
I'm only running as root for testing purposes instead of manually entering
information for the xauth allow list. I've been doing it for quite some
time, and it's always worked fine with native OpenCL/OpenGL interop as well
as with pycuda's interop so I don't think it's the issue.

Just to confirm though, I went ahead and tested with non-root and the only
difference is that it indicates that a segmentation fault occurs during the
cl calls:

> DISPLAY=:0 python gl_particle_animation.py

Xlib:  extension "NV-GLX" missing on display "P".
zsh: segmentation fault (core dumped)  DISPLAY=:0 python
gl_particle_animation.py



--
Aaron

On Wed, Apr 12, 2017 at 5:17 PM, Andreas Kloeckner 
wrote:

> Aaron Myles Landwehr  writes:
>
> > Hi Andreas,
> >
> > Here is the pyopencl platform information:
> >
> >> sudo DISPLAY=:0 python opencl-print-info.py
> > PyOpenCL version: 2016.2.1
> > OpenCL header version: 1.2
>
> 'sudo' may interfere with the Nv driver's ability to connect with other
> (e.g. kernel) parts of the driver? Why are you using that?
>
> Andreas
>
___
PyOpenCL mailing list
PyOpenCL@tiker.net
https://lists.tiker.net/listinfo/pyopencl


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Andreas Kloeckner
Aaron Myles Landwehr  writes:

> Hi Andreas,
>
> Here is the pyopencl platform information:
>
>> sudo DISPLAY=:0 python opencl-print-info.py
> PyOpenCL version: 2016.2.1
> OpenCL header version: 1.2

'sudo' may interfere with the Nv driver's ability to connect with other
(e.g. kernel) parts of the driver? Why are you using that?

Andreas

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


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Aaron Myles Landwehr
Hi Andreas,

Here is the pyopencl platform information:

> sudo DISPLAY=:0 python opencl-print-info.py
PyOpenCL version: 2016.2.1
OpenCL header version: 1.2

- Installed platforms (SDKs) and available devices:
NVIDIA CUDA (NVIDIA Corporation)
Version: OpenCL 1.2 CUDA 8.0.0
Profile: FULL_PROFILE
Extensions: ['cl_khr_global_int32_base_atomics',
'cl_khr_global_int32_extended_atomics', 'cl_khr_local_int32_base_atomics',
'cl_khr_local_int32_extended_atomics', 'cl_khr_fp64',
'cl_khr_byte_addressable_store', 'cl_khr_icd', 'cl_khr_gl_sharing',
'cl_nv_compiler_options', 'cl_nv_device_attribute_query',
'cl_nv_pragma_unroll', 'cl_nv_copy_opts', 'cl_khr_gl_event']
Available devices:
Quadro K5000 (NVIDIA Corporation)
Version: OpenCL 1.2 CUDA
Type:GPU
Extensions:  ['cl_khr_global_int32_base_atomics',
'cl_khr_global_int32_extended_atomics', 'cl_khr_local_int32_base_atomics',
'cl_khr_local_int32_extended_atomics', 'cl_khr_fp64',
'cl_khr_byte_addressable_store', 'cl_khr_icd', 'cl_khr_gl_sharing',
'cl_nv_compiler_options', 'cl_nv_device_attribute_query',
'cl_nv_pragma_unroll', 'cl_nv_copy_opts', 'cl_khr_gl_event']
Memory (global): 4232183808
Memory (local):  49152
Address bits:64
Max work item dims:  3
Max work group size: 1024
Max compute units:   8
Driver version:  375.51
Image support:   True
Little endian:   True
Device available:True
Compiler available:  True

The following code displays 'NVIDIA CUDA' as the platform:

print(cl.get_platforms()[0])
platform = cl.get_platforms()[0]
context = cl.Context(properties=[(cl.context_properties.PLATFORM,
platform)] + get_gl_sharing_context_properties())
queue = cl.CommandQueue(context)




--
Aaron

On Wed, Apr 12, 2017 at 2:08 PM, Andreas Kloeckner 
wrote:

> Aaron Myles Landwehr  writes:
> > I'm using NVs driver, the xorg log confirms this (as well as the glx
> > extensions being loaded) and Opencl and Cuda also work outside of
> pyopencls
> > interop code (they require the NV driver to function). At this point, I'm
> > thinking the pointer to the context is probably incorrect and that's
> > probably why I'm seeing weird P and Rs printed as the display name since
> > incorrect memory would likely be referenced in that case.
>
> Not sure how the 'wrong context' bit would happen--can you print
> e.g. context.platform.name or something to ensure you're talking to the
> right thing?
>
> Btw, please make sure the list stays cc'd.
>
> Andreas
>
>
___
PyOpenCL mailing list
PyOpenCL@tiker.net
https://lists.tiker.net/listinfo/pyopencl


Re: [PyOpenCL] opengl interop not working on SL 7.2

2017-04-12 Thread Andreas Kloeckner
Aaron Myles Landwehr  writes:
> I'm using NVs driver, the xorg log confirms this (as well as the glx
> extensions being loaded) and Opencl and Cuda also work outside of pyopencls
> interop code (they require the NV driver to function). At this point, I'm
> thinking the pointer to the context is probably incorrect and that's
> probably why I'm seeing weird P and Rs printed as the display name since
> incorrect memory would likely be referenced in that case.

Not sure how the 'wrong context' bit would happen--can you print
e.g. context.platform.name or something to ensure you're talking to the
right thing?

Btw, please make sure the list stays cc'd.

Andreas


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