Re: [PyOpenCL] opengl interop not working on SL 7.2
It seems possible that an incorrect context is being returned by pyopencl in Linux. I found the following post indicating that there is a bug causing incorrect device contexts to be returned in Windows. Unfortunately, the solution highlighted doesn't work in Linux. http://stackoverflow.com/questions/38294154/pyopencl-gl-sharing-context-creation-failed-overflow-error -- Aaron Myles Landwehr On Wed, Apr 12, 2017 at 2:30 AM, Aaron Myles Landwehr wrote: > I've compiled pyopencl with opengl interop however it doesn't appear to > work with the newest release of pyopencl. I receive the following error > running the gl_particle_animation.py example: > > Xlib: extension "NV-GLX" missing on display "P". > > > I've tested various interop examples and it seems to be the case that once > a cl function is called, the program will exit with or without the error > without running any kernel code (it seems racey whether or not it appears). > I've also seen the same error with the slight variation of: > > Xlib: extension "NV-GLX" missing on display "R". > > The display name seems odd to me since I'm simply running :0 as usual. > > Some other important information: > >- The platform is SL 7.2 x64 with a K5000 using the newest revision of >the CUDA Toolkit and Drivers >- pyopencl without interop buffers works fine. pyopengl also works >fine. >- Interop works in native OpenCL, CUDA, and pycuda. It only appears >broken with pyopencl. > > Any ideas? > > Thanks, > -- > Aaron Myles Landwehr > > ___ PyOpenCL mailing list PyOpenCL@tiker.net https://lists.tiker.net/listinfo/pyopencl
Re: [PyOpenCL] opengl interop not working on SL 7.2
Aaron Myles Landwehr writes: > I've compiled pyopencl with opengl interop however it doesn't appear to > work with the newest release of pyopencl. I receive the following error > running the gl_particle_animation.py example: > > Xlib: extension "NV-GLX" missing on display "P". > > > I've tested various interop examples and it seems to be the case that once > a cl function is called, the program will exit with or without the error > without running any kernel code (it seems racey whether or not it appears). > I've also seen the same error with the slight variation of: > > Xlib: extension "NV-GLX" missing on display "R". > > The display name seems odd to me since I'm simply running :0 as usual. > > Some other important information: > >- The platform is SL 7.2 x64 with a K5000 using the newest revision of >the CUDA Toolkit and Drivers >- pyopencl without interop buffers works fine. pyopengl also works fine. >- Interop works in native OpenCL, CUDA, and pycuda. It only appears >broken with pyopencl. > > Any ideas? This looks like you might be using non-Nvidia display drivers (nouveau likely). Andreas ___ PyOpenCL mailing list PyOpenCL@tiker.net https://lists.tiker.net/listinfo/pyopencl
Re: [PyOpenCL] opengl interop not working on SL 7.2
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
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
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
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
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
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
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
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
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
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
Tested and it works using the master branch from the git repo. Thanks! -- Aaron Myles Landwehr On Fri, Apr 14, 2017 at 11:21 AM, Andreas Kloeckner wrote: > 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/21008183734b9d13ae2c40ea2e3bde > c20ac70250 > > 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
