I removed the file nvidia.icd from /etc/OpenCL/vendors/ and then i tried
the above mentioned command
*echo libnvidia-opencl.so.1 >> /etc/OpenCL/vendors/nvidia.icd*
and it worked. but i still get the same error when running following code:
import pyopencl as cl
cl.get_platforms()
clGetPlatformIDs failed: <unknown error -1001>
On Sun, Mar 11, 2018 at 4:58 PM, aseem hegshetye <aseem.hegshetye(a)gmail.com>
wrote:
> I was able to log in as root user by doing "sudo -i" after ssh to the aws
> ec2 instance.
>
> but now the command *echo libnvidia-opencl.so.1 >>
> /etc/OpenCL/vendors/nvidia.icd* says
>
> " -bash: /etc/OpenCL/vendors/nvidia.icd: No such file or directory"
>
> On Sun, Mar 11, 2018 at 5:51 AM, aseem hegshetye <
> aseem.hegshetye(a)gmail.com> wrote:
>
>> is there a way around to solve this without being a root user?
>>
>>
>>
>> On Sun, Mar 11, 2018 at 1:34 AM, Andreas Kloeckner <
>> lists(a)informa.tiker.net> wrote:
>>
>>> aseem hegshetye <aseem.hegshetye(a)gmail.com> writes:
>>>
>>> > Hi,
>>> > I get this error when i run following code:
>>> >
>>> > *import pyopencl as cl*
>>> > *cl.get_platforms()*
>>> >
>>> > I tried following command in ubuntu terminal to fix it:
>>> > * sudo echo e- 'echo libnvidia-opencl.so.1' >>
>>> > /etc/OpenCL/vendors/nvidia.icd*
>>> > and
>>> > *echo libnvidia-opencl.so.1 >> /etc/OpenCL/vendors/nvidia.icd*
>>> >
>>> > But i get permission denied error.
>>>
>>> Only writable as root.
>>>
>>> Andreas
>>>
>>
>>
>
I was able to log in as root user by doing "sudo -i" after ssh to the aws
ec2 instance.
but now the command *echo libnvidia-opencl.so.1 >>
/etc/OpenCL/vendors/nvidia.icd* says
" -bash: /etc/OpenCL/vendors/nvidia.icd: No such file or directory"
On Sun, Mar 11, 2018 at 5:51 AM, aseem hegshetye <aseem.hegshetye(a)gmail.com>
wrote:
> is there a way around to solve this without being a root user?
>
>
>
> On Sun, Mar 11, 2018 at 1:34 AM, Andreas Kloeckner <
> lists(a)informa.tiker.net> wrote:
>
>> aseem hegshetye <aseem.hegshetye(a)gmail.com> writes:
>>
>> > Hi,
>> > I get this error when i run following code:
>> >
>> > *import pyopencl as cl*
>> > *cl.get_platforms()*
>> >
>> > I tried following command in ubuntu terminal to fix it:
>> > * sudo echo e- 'echo libnvidia-opencl.so.1' >>
>> > /etc/OpenCL/vendors/nvidia.icd*
>> > and
>> > *echo libnvidia-opencl.so.1 >> /etc/OpenCL/vendors/nvidia.icd*
>> >
>> > But i get permission denied error.
>>
>> Only writable as root.
>>
>> Andreas
>>
>
>
aseem hegshetye <aseem.hegshetye(a)gmail.com> writes:
> Hi,
> I get this error when i run following code:
>
> *import pyopencl as cl*
> *cl.get_platforms()*
>
> I tried following command in ubuntu terminal to fix it:
> * sudo echo e- 'echo libnvidia-opencl.so.1' >>
> /etc/OpenCL/vendors/nvidia.icd*
> and
> *echo libnvidia-opencl.so.1 >> /etc/OpenCL/vendors/nvidia.icd*
>
> But i get permission denied error.
Only writable as root.
Andreas
Hi,
I get this error when i run following code:
*import pyopencl as cl*
*cl.get_platforms()*
I tried following command in ubuntu terminal to fix it:
* sudo echo e- 'echo libnvidia-opencl.so.1' >>
/etc/OpenCL/vendors/nvidia.icd*
and
*echo libnvidia-opencl.so.1 >> /etc/OpenCL/vendors/nvidia.icd*
But i get permission denied error.
How can i fix it.
thanks
Aseem
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 (wx3(a)msn.com) wrote:
http://pyopencl.tiker.narkive.com/Kq2NgLWF/unanble-to-run-either-gl-interop…
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-bounces(a)tiker.net> on behalf of Erik Zorzin - HOME <erik(a)zorzin.com>
Sent: Thursday, March 8, 2018 12:10 AM
To: pyopencl(a)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 (lists(a)informa.tiker.net) wrote:
Erik Zorzin - HOME <erik(a)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
I think this is a good, simple & platform independent approach. There are
very few options when using pyopencl on nvidia GPUs.
Aseem
On Fri, Mar 9, 2018 at 10:09 PM, Karl Czajkowski <karlcz(a)isi.edu> wrote:
> On Mar 09, aseem hegshetye modulated:
> > Hi,
> > Is there a way to debug and/or print intermediate variables while
> running a c kernel on GPu via pyopencl.
> >
>
>
> This may sound funny, but if the problem isn't too irregular, I have
> sometimes found it valuable to use ndarray outputs as a "printf".
> Each kernel task has a different index into the array and outputs its
> intermediate variable(s) along another temporal axis. Then, I
> visualize the ndarray on the host by applying color mapping and
> slicing through the array to see patterns where each kernel has a
> state mapped to a pixel.
>
>
> Karl
>
Hi,
Is there a way to debug and/or print intermediate variables while running a c kernel on GPu via pyopencl.
Debugging is very painful for GPu kernels. Currently I have loop over number of threads in my local machine.
Aseem
Hello.
I'm preparing new upload of PyOpenCL (and related packages).
Andreas - can you tag 2018.1.1 in git? There is tag for 2018.1,
but not one for 2018.1.1. It's not urgent: I still want to fix
some issues pointed by lintian, and look at Multi-Arch before
uploading. But I'd like to avoid putting bare commit-id to
package.
Thanks in advance.
--
Tomasz Rybak, Debian Developer
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C
Hi,
I am desperate :)
I am trying to install PyOpenCL on a Linux machine (Manjaro, arch-based) for several days now.
I have an Nvidia GeForce GT640, I have installed the last drivers, OpenCL, OpenGL, ... everything.
I have installed PyOpenCL with the --cl_enable_gl flag.
I have the correct drivers and OpenGL libraries (as far I can see from glxinfo | grep OpenGL).
My problem is that I cannot run any code involving the GL interop.
The situation looks very similar to what described here:
https://lists.tiker.net/pipermail/pyopencl/2017-April/002285.html
but in my case I had a look the the cffi_cl.py file and it looks in the version I have the bug has been corrected already by the developers.
Every time I try to get a context this way:
...
ctx = cl.Context(properties=[(cl.context_properties.PLATFORM, platform)] + get_gl_sharing_properties(), devices = [platform.get_devices()[0]])
...
the python script crashes with a "Segmentation fault (core dumped)".
dmesg gives many errors like:
...
segfault at XXXXXX ip YYYY sp ZZZZZZZZ error 5 in libGLX_nvidia.so.390.25
segfault at XXXXXX ip YYYY sp ZZZZZZZZ error 4 in libGLX_nvidia.so.390.25
...
However, if I compile and run the interop examples written in C in the Nvidia SDK everything works fine. For this I am sure my environment works.
All my interop python scripts are perfectly working on another computer (MacBook Air) where I have another installation of PyOpenCL.
Do you have any suggestion? Could this be a bug somewhere 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)