Segmentation fault in pyopencl.image_from_array
by Jerome Kieffer
Dear Python/OpenCL community,
I am pretty new (py)opencl and encountered a problem, maybe it a lack of understanding of openCL, but I found strange python seg-faults:
test program:
#!/usr/bin/python
import numpy, pyopencl
ctx = pyopencl.create_some_context()
data=numpy.random.random((1024,1024)).astype(numpy.float32)
img = pyopencl.image_from_array(ctx, ary=data, mode="r", norm_int=False, num_channels=1)
print img
System: debian sid: pyopencl2012.1 (the same code works with debian stable and v2011.2)
Here is the backtrace obtained with GDB:
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff340c253 in pyopencl::create_image_from_desc(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object) () from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so
#2 0x00007ffff342de36 in _object* boost::python::detail::invoke<boost::python::detail::install_holder<pyopencl::image*>, pyopencl::image* (*)(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object), boost::python::arg_from_python<pyopencl::context const&>, boost::python::arg_from_python<unsigned long>, boost::python::arg_from_python<_cl_image_format const&>, boost::python::arg_from_python<_cl_image_desc&>, boost::python::arg_from_python<boost::python::api::object> >(boost::python::detail::invoke_tag_<false, false>, boost::python::detail::install_holder<pyopencl::image*> const&, pyopencl::image* (*&)(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object), boost::python::arg_from_python<pyopencl::context const&>&, boost::python::arg_from_python<unsigned long>&, boost::python::arg_from_python<_cl_image_format const&>&, boost::python::arg_from_python<_cl_image_desc&>&, boost::python::arg_from_python<boost::python::api::object>&) () from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so
#3 0x00007ffff342e06f in boost::python::detail::caller_arity<5u>::impl<pyopencl::image* (*)(pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object), boost::python::detail::constructor_policy<boost::python::default_call_policies>, boost::mpl::vector6<pyopencl::image*, pyopencl::context const&, unsigned long, _cl_image_format const&, _cl_image_desc&, boost::python::api::object> >::operator()(_object*, _object*) ()
from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so
#4 0x00007ffff311715b in boost::python::objects::function::call(_object*, _object*) const ()
from /usr/lib/libboost_python-py27.so.1.49.0
#5 0x00007ffff3117378 in ?? () from /usr/lib/libboost_python-py27.so.1.49.0
#6 0x00007ffff3120593 in boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const ()
from /usr/lib/libboost_python-py27.so.1.49.0
#7 0x00007ffff3445983 in boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<pyopencl::error, void (*)(pyopencl::error const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(pyopencl::error const&)> > >, bool, boost::python::detail::exception_handler const&, boost::function0<void> const&>::invoke(boost::detail::function::function_buffer&, boost::python::detail::exception_handler const&, boost::function0<void> const&) () from /usr/lib/python2.7/dist-packages/pyopencl/_cl.so
#8 0x00007ffff3120373 in boost::python::handle_exception_impl(boost::function0<void>) ()
from /usr/lib/libboost_python-py27.so.1.49.0
#9 0x00007ffff3115635 in ?? () from /usr/lib/libboost_python-py27.so.1.49.0
Thanks for your help.
If you are not able to reproduce this bug, I should mention it to debian.
Cheers,
--
Jérôme Kieffer
Data analysis unit - ESRF
5 years, 9 months
create Event from cl_event
by Gregor Thalhammer
Dear Andreas,
I am currently working on a cython based wrapper for the OpenCL FFT library from AMD: https://github.com/geggo/gpyfft
For this I need to create a pyopencl Event instance from a cl_event returned by the library. I attached a patch against recent pyopencl that adds this possibility, similar to the from_cl_mem_as_int() method of the MemoryObject class. Could you please add this to pyopencl.
Thanks for your help
Gregor
6 years, 4 months
About PyOpenCL on Apple computer ...
by Jerome Kieffer
Hello,
I spent the day in porting a pyopencl application from Linux to MacOSX.
I don't blame pyopencl at all but I found the porting was quite
difficult for a couple of portable tools like python and OpenCL.
I am working on a freshly installed MacOSX Lion on a MacBook Pro from
2008 with a dual core "core2" from intel and two GPUs from NVidia 9400M
and 9600M.
First bug: "RuntimeError: Device not available"
I selected the most powerfull GPU when creating the context but the queue creation failed ... It seems only the gfxCardStatus external tool is able to activate (actually switch) GPUs.
Question: Is there a way within PyOpenCL to know if a device is actually available or not ?
The flag: device.available is set to 1 regardless if the GPU is actually ON or OFF. The only unacceptable solution I found is based on try/except :(
try: queue=pyopencl.CommandQueue(ctx)
except RuntimeError: print("Sorry, switched off")
Second bug: "pyopencl.RuntimeError: clBuildProgram failed: build program failure"
Solution: options to build the kernel need to be stripped under MacOSX !!!
Third bug: "LogicError: clEnqueueNDRangeKernel failed: invalid work group size"
When running on CPU, I have the fealing that the only valid workgroup size is "1", even when
device.max_work_group_size advertizes 1024 !!!
I found track of such bugs on this mailing list and others but I have the feeling the community developing opencl application on MacOSX is not that large, am I wrong ?
Cheers.
--
Jérôme Kieffer
Data analysis unit - ESRF
7 years
Re: [PyOpenCL] Initial pyopencl with multiprocessing
by Andreas Kloeckner
Hi Jonny,
Jonathan Hunt <hunt(a)braincorporation.com> writes:
> If I run the code below (using pyopencl after fork) I get an
> LogicError: clGetContextInfo failed: invalid context. I guess what is
> happening is that the CL library needs to be initialized again in a
> new process.
>
> I have tried various combinations of reload(cl) reload(cl._cl) and
> calling cl.__init__ etc to no avail.
>
> The reason I want to this is that I'm using pytest with --boxed option
> (every test is run in a seperate process) (my tests don't call
> os.fork() explicitly - that's just to recreate the error without
> pytest).
>
> Any tips on how to workaround this appreciated. This is OS X 10.8.2
> (with Apple CL).
Uh, that's pretty dire. "import pyopencl" doesn't call a single OpenCL
function. It just loads the OpenCL C library. If that alone destroys
fork(), then there's little that it as a library can do. If you can,
perhaps import pyopencl after you fork...?
Andreas
7 years
Initial pyopencl with multiprocessing
by Jonathan Hunt
Hi,
If I run the code below (using pyopencl after fork) I get an
LogicError: clGetContextInfo failed: invalid context. I guess what is
happening is that the CL library needs to be initialized again in a
new process.
I have tried various combinations of reload(cl) reload(cl._cl) and
calling cl.__init__ etc to no avail.
The reason I want to this is that I'm using pytest with --boxed option
(every test is run in a seperate process) (my tests don't call
os.fork() explicitly - that's just to recreate the error without
pytest).
Any tips on how to workaround this appreciated. This is OS X 10.8.2
(with Apple CL).
Thanks,
Jonny
import pytest
import logging
import os
import imp
import sys
import pyopencl as cl
#cl = pytest.importorskip("pyopencl")
def test_create_some_context():
ctx = cl.create_some_context(interactive = False)
if os.fork() == 0:
ctx = cl.create_some_context(interactive = False)
print('Ctx created was %s' % str(ctx))
test_create_some_context()
7 years
Re: [PyOpenCL] Compiling in Fedora 17
by Andreas Kloeckner
Daniel <ddshore(a)hotmail.com> writes:
> Thanks,
> I'm a bit confused, optimus would mean I would have to use the intel one
> right? (since optimus is nvidia + intel)?
No, these use the *CPU* as the compute device and have nothing to do
with GPUs or any GPU-related technology like Optimus.
> The implementation is only for windows,
? I'm using the Intel CL implementation on Linux. There's a "Linux"
option in the dropdown box.
> and the AMD includes linux but
> doesn't support my nVidia card (I guess).
No, see above.
Andreas
7 years
operating on components of vectors
by Ajay Shah
Hello,
This is something I'm a bit stumped on.
I know how to operate on two vectors by using "Adventures in Pyopencl", but when I use components of a vector to do operations, I get the wrong results. when printing the results, c = a zero vector.
Could you look at my simple code?
from numpy import *import pyopencl as cl
ctx = cl.create_some_context()queue = cl.CommandQueue(ctx)fstr = "__kernel void part1(__global float* a, __global float* b,__global float* c,){ unsigned int i = get_global_id(0); float value = 0; value = (a[i] + b[i]); c[i] = value ; }"program = cl.Program(ctx,fstr).build()
o = array([range(10),range(10)])a = o[0,:]b = o[1,:]
mf = cl.mem_flagsa_buf = cl.Buffer(ctx,mf.READ_ONLY | mf.COPY_HOST_PTR, hostbuf = a.copy())b_buf = cl.Buffer(ctx,mf.READ_ONLY | mf.COPY_HOST_PTR, hostbuf = b.copy())dest_buf = cl.Buffer(.ctx, mf.WRITE_ONLY, b.nbytes) program.part1(queue, a.shape, None, a_buf, b_buf,dest_buf)c = empty_like(a)cl.enqueue_read_buffer(queue, dest_buf, c).wait()
Thanks,
Ajay
7 years
Re: [PyOpenCL] Compiling in Fedora 17
by Andreas Kloeckner
Hi Daniel,
Daniel <ddshore(a)hotmail.com> writes:
> I'm trying to compile in Fedora 17, and finally managed to do it after some
> adjustments. However, when trying to run examples/demo.py
>
> File "demo.py", line 1, in <module>
> import pyopencl as cl
> File
> "/usr/lib64/python2.7/site-packages/pyopencl-2012.1-py2.7-linux-x86_64.egg/pyopencl/__init__.py",
> line 4, in <module>
> import pyopencl._cl as _cl
> ImportError:
> /usr/lib64/python2.7/site-packages/pyopencl-2012.1-py2.7-linux-x86_64.egg/pyopencl/_cl.so:
> undefined symbol: clCreateSubDevices
>
> I thought that maybe I had compiled with opencl 1.1 and it turned out I had
> (kind of, I had a mixture of files from khronos). So I downloaded only the
> 1.2 files and recompiled (by untaring again) but I still get the same
> error. I'm not sure if the error comes from my previous installation, or
> if there is something else that I'm doing wrong.
Solution: Add
CL_PRETEND_VERSION = "1.1"
to siteconf.py.
Problem: If you feed PyOpenCL headers for CL 1.2 and then compile
against an ICD loader that doesn't implement 1.2 functions
(e.g. clCreateSubDevice), then you get this breakage. The above fixes
that, by forcing PyOpenCL to ignore 1.2.
Andreas
7 years
