Class Context is missing attribute DEVICES?
by David Garcia
Hi Andreas & folks,
I just downloaded and installed pyopencl 0.91 to try the changes. The code
looks cleaner now that we have constructors. Thanks a lot :)
However, when I tried executing the code below I get an error:
>>> ctx = cl.create_context_from_type(cl.device_type.CPU)>>> ctx.DEVICES
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/Library/Python/2.6/site-packages/pyopencl-0.91-py2.6-macosx-10.6-i386.egg/pyopencl/__init__.py",
line 67, in result
% (type(self), name))
AttributeError: <class 'pyopencl._cl.Context'> has no attribute 'DEVICES'
If I do this then it works:
>>> ctx = cl.create_context_from_type(cl.device_type.CPU)
>>> ctx.get_info(cl.context_info.DEVICES)
[<pyopencl._cl.Device object at 0x10142f2f0>]
Cheers,
David
10 years, 2 months
Opencl problem under mac10.6 wrong architecture
by Jassin MEKNASSI
>
> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib is just a symlink link
> to /usr/local/lib.
> won't fix the prob
> thanks.
>
> On Sep 15, 2009, at 4:04 PM, James Snyder wrote:
>
>>
>> On Sep 15, 2009, at 1:55 PM, Andreas Klöckner wrote:
>>
>>> Hi Jassin,
>>>
>>> a) please don't email me directly. Instead, please use the mailing
>>> list.
>>>
>>> b) It looks like you have a boost version mismatch, i.e. the
>>> headers for the
>>> boost library which you are using for the compilation don't match
>>> the library
>>> that gets found at run time. Check for multiple installations of
>>> Boost.
>>
>> I concur, it looks as if you might have a version of boost being
>> found at link time and one being found later when dynamic lookup
>> takes place.
>>
>> If I had to guess, based on the compiler messages and the later
>> message, you're linking against an install of boost that went into
>> your 10.6 SDK directory (not sure why), and later it is using the
>> one from /usr/local/lib.
>>
>> You could check if the dynamic lookups work if you include /
>> Developer/SDKs/MacOSX10.6.sdk/usr/local/lib in your
>> DYLD_LIBRARY_PATH. I'm not sure if that's a good idea in the long
>> run though. I might remove the boost libraries & headers from the
>> SDK dir, make sure you have the correct version in /usr/local/lib
>> or wherever you wish to have them installed, and then try
>> rebuilding things.
>>
>>>
>>> HTH,
>>> Andreas
>>>
>>> On Dienstag 15 September 2009, you wrote:
>>>> hi i tried to install opencl under macosx 10.6.1 unfortunnatly when
>>>> starting the example i get :
>>>>
>>>> python test_wrapper.py
>>>> Traceback (most recent call last):
>>>> File "test_wrapper.py", line 205, in <module>
>>>> import pyopencl
>>>> File
>>>> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
>>>> site-pack
>>>> ages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/
>>>> __init__.py", line 3,
>>>> in <module> import pyopencl._cl as _cl
>>>> ImportError:
>>>> dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/
>>>> python2.6/sit
>>>> e-packages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/
>>>> _cl.so, 2):
>>>> Symbol not found:
>>>> __ZNK5boost6python7objects21py_function_impl_base9max_arityEv
>>>> Referenced
>>>> from:
>>>> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
>>>> site-packa
>>>> ges/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so
>>>> Expected in:
>>>> dynamic lookup
>>>>
>>>>
>>>>
>>>> during make i get :
>>>>
>>>> ld: warning: in
>>>> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
>>>> libboost_python.dylib, file
>>>> is not of required architecture ld: warning: in
>>>> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
>>>> libboost_thread.dylib, file
>>>> is not of required architecture
>>>>
>>>>
>>>> what is /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib ?
>>
>> That architecture complaint may be OK. I think this may just be
>> because boost is built for x86_64 and the other libraries (OpenCL,
>> Python, etc..) are fat binaries with i386 and x86_64. I get the
>> complaint that the libboost_* libraries I'm using aren't of the
>> required architecture.
>>
>> I'm not sure why they're installed in that location though. My
>> 10.6 SDK doesn't have boost libraries there.
>>
>>>>
>>>> my specs are :
>>>>
>>>> gcc version 4.2.1 (Apple Inc. build 5646)
>>>> boost 1.40 /usr/local/include and /usr/local/lib
>>
>> Looks like you've got a version installed in /Developer/SDKs/
>> MacOSX10.6.sdk/usr/local/lib as well?
>>
>>>> Python 2.6.2
>>>> Numpy 1.3.0
>>>>
>>>> did the same way you described under the wiki
>>>>
>>>> python configure.py --boost-inc-dir=/usr/local/include
>>>> --boost-lib-dir=/usr/local/lib --boost-python-
>>>> libname=boost_python
>>>> --boost-thread-libname=boost_thread --cl-libname=''
>>>> --ldflags='-Wl,-framework,OpenCL' --boost-compiler='gcc42'
>>>>
>>>> echo $DYLD_LIBRARY_PATH : /usr/local/lib:/usr/local/cuda/lib
>>>>
>>>> Any idea?
>>>>
>>>>
>>>> thank you very much in advance. I m very exited about the
>>>> pyOpencl project
>>>>
>>>
>>> _______________________________________________
>>> PyOpenCL mailing list
>>> PyOpenCL(a)tiker.net
>>> http://tiker.net/mailman/listinfo/pyopencl_tiker.net
>>
>> --
>> James Snyder
>> Biomedical Engineering
>> Northwestern University
>> jbsnyder(a)fanplastic.org
>> http://fanplastic.org/key.txt
>> ph: 847.448.0386
>>
>>
>>
>>
>
10 years, 2 months
Re: [PyOpenCL] Opencl problem under mac10.6 wrong architecture
by Andreas Klöckner
Hi Jassin,
a) please don't email me directly. Instead, please use the mailing list.
b) It looks like you have a boost version mismatch, i.e. the headers for the
boost library which you are using for the compilation don't match the library
that gets found at run time. Check for multiple installations of Boost.
HTH,
Andreas
On Dienstag 15 September 2009, you wrote:
> hi i tried to install opencl under macosx 10.6.1 unfortunnatly when
> starting the example i get :
>
> python test_wrapper.py
> Traceback (most recent call last):
> File "test_wrapper.py", line 205, in <module>
> import pyopencl
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-pack
> ages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/__init__.py", line 3,
> in <module> import pyopencl._cl as _cl
> ImportError:
> dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/sit
> e-packages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so, 2):
> Symbol not found:
> __ZNK5boost6python7objects21py_function_impl_base9max_arityEv Referenced
> from:
> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packa
> ges/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so Expected in:
> dynamic lookup
>
>
>
> during make i get :
>
> ld: warning: in
> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/libboost_python.dylib, file
> is not of required architecture ld: warning: in
> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/libboost_thread.dylib, file
> is not of required architecture
>
>
> what is /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib ?
>
> my specs are :
>
> gcc version 4.2.1 (Apple Inc. build 5646)
> boost 1.40 /usr/local/include and /usr/local/lib
> Python 2.6.2
> Numpy 1.3.0
>
> did the same way you described under the wiki
>
> python configure.py --boost-inc-dir=/usr/local/include
> --boost-lib-dir=/usr/local/lib --boost-python-libname=boost_python
> --boost-thread-libname=boost_thread --cl-libname=''
> --ldflags='-Wl,-framework,OpenCL' --boost-compiler='gcc42'
>
> echo $DYLD_LIBRARY_PATH : /usr/local/lib:/usr/local/cuda/lib
>
> Any idea?
>
>
> thank you very much in advance. I m very exited about the pyOpencl project
>
10 years, 2 months
Re: [PyOpenCL] Opencl problem under mac10.6 wrong architecture
by Jassin MEKNASSI
Thanks for the reply. I subscribed to the mailing list.
b)
i looked up any other boost installation with find / -name libboost*
and found only one version.
I did uninstall boost by using rm libboost* in /usr/local/lib
reinstalled with
sudo ./bootstrap.sh --prefix=/usr/local --libdir=/usr/local/lib
&&
sudo ./bjam -j4 variant=release link=shared install
but i still get
g++ -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-
fat-2.6/src/wrapper/wrap_cl.o -L/usr/local/lib -lboost_python -
lboost_thread -o build/lib.macosx-10.3-fat-2.6/pyopencl/_cl.so -Wl -
framework OpenCL -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -
arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk
ld: warning: in /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
libboost_python.dylib, file is not of required architecture
ld: warning: in /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/
libboost_thread.dylib, file is not of required architecture
Thanks for the help
Hi Jassin,
a) please don't email me directly. Instead, please use the mailing list.
b) It looks like you have a boost version mismatch, i.e. the headers
for the
boost library which you are using for the compilation don't match the
library
that gets found at run time. Check for multiple installations of Boost.
HTH,
Andreas
On Dienstag 15 September 2009, you wrote:
> hi i tried to install opencl under macosx 10.6.1 unfortunnatly when
> starting the example i get :
>
> python test_wrapper.py
> Traceback (most recent call last):
> File "test_wrapper.py", line 205, in <module>
> import pyopencl
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
> site-pack
> ages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/__init__.py",
> line 3,
> in <module> import pyopencl._cl as _cl
> ImportError:
> dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/
> python2.6/sit
> e-packages/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so,
> 2):
> Symbol not found:
> __ZNK5boost6python7objects21py_function_impl_base9max_arityEv
> Referenced
> from:
> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-
> packa
> ges/pyopencl-0.91-py2.6-macosx-10.3-fat.egg/pyopencl/_cl.so Expected
> in:
> dynamic lookup
>
>
>
> during make i get :
>
> ld: warning: in
> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/libboost_python.dylib,
> file
> is not of required architecture ld: warning: in
> /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/libboost_thread.dylib,
> file
> is not of required architecture
>
>
> what is /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib ?
>
> my specs are :
>
> gcc version 4.2.1 (Apple Inc. build 5646)
> boost 1.40 /usr/local/include and /usr/local/lib
> Python 2.6.2
> Numpy 1.3.0
>
> did the same way you described under the wiki
>
> python configure.py --boost-inc-dir=/usr/local/include
> --boost-lib-dir=/usr/local/lib --boost-python-libname=boost_python
> --boost-thread-libname=boost_thread --cl-libname=''
> --ldflags='-Wl,-framework,OpenCL' --boost-compiler='gcc42'
>
> echo $DYLD_LIBRARY_PATH : /usr/local/lib:/usr/local/cuda/lib
>
> Any idea?
>
>
> thank you very much in advance. I m very exited about the pyOpencl
> project
10 years, 2 months
ANN: 0.91
by Andreas Klöckner
Hi all,
I've just release PyOpenCL 0.91. Based on the discussions today, I've gotten
rid of many of the create_something() functions and replaced them by
constructors. Feels much nicer, to me at least.
Old code should continue to work, with warnings.
Happy hacking, and let me know if something's amiss,
Andreas
10 years, 2 months
Re: [PyOpenCL] Creating image formats is cumbersome
by David Garcia
>From your heading I guess you also wanted to CC the mailing list, so I've
added it back.
I'm not personally concerned about backwards compatibility at this stage. I
assumed that until pyopencl 1.0 was released the API would logically be in
flux.
I didn't realize that any function in the native API with more than one
parameter becomes a function in pyopencl --the get-info methods seem to be
an exception, though. As long as we have some simple objective rules to map
the native API to python I'll be happy. Can we make these rules explicit
now? I infer that the current rules are something like this:
1. Remove the "cl_", "CL_" and "cl" prefix from data types, macros and
function names.
2. Make function names lowercase.
3. If a data type or function name is composed of more than one word,
separate the words with a single underscore.
4. get-info functions become attributes. (I like this a lot, by the way :)
I've surely made some mistakes above and I know I've missed some stuff as
well. Please correct me where I'm wrong.
Cheers,
David
2009/9/13 Andreas Klöckner <lists(a)informa.tiker.net>
> Hi David, all,
>
> first of all, if you're reading this and wondering if whatever code you've
> written will become worthless just because we willy-nilly decide to
> introduce
> some broad API change, let me calm you. I consider PyOpenCL's API "stable".
> That doesn't mean it can't change. But if it does, your code will generally
> continue to run. It may start spewing warnings about things you need to
> change
> to stay compatible with future versions.
>
> Since we're fixing policy right now: Deprecation warnings will be around
> for a
> whole release cycle, as identified by the second number in the release
> name.
> (the "90" in "0.90") Further, the stability promise applies for any code
> that's part of a released version. It doesn't apply to undocumented bits of
> the API, and it doesn't apply to unreleased code downloaded from git.
>
> On Sonntag 13 September 2009, you wrote:
> > My argument is simple: OpenCL is designed as an object-oriented API
> exposed
> > in C, which is a non-object-oriented language. Notice how in OpenCL,
> unlike
> > in OpenGL, there is no state machine. In other words, only objects have
> > state.
> >
> > Given the choice I would have probably written a direct one-to-one
> mapping
> > of OpenCL in Python in order to make it easier to port code from one
> > language to the other and to respect the principle of least surprise.
> > Developers that know native OpenCL could start using it in Python right
> > away without having to learn yet another API. I understand that this
> > approach would not make the code look pythonic. However, this was the
> > solution chosen for other similar APIs such as the Java bindings of
> OpenGL
> > (JOGL) and whoever is using OpenCL already needs to be comfortable with
> > C99 in order to write the kernels.
> >
> > This said, I wouldn't make a fuss if the bindings of OpenCL in other
> > languages made CL's object-oriented design explicit. This is what some
> > folks at AMD did -- I wasn't involved in this but I from what I see it
> > looks pretty elegant. The underlying idea is that if you know OpenCL's C
> > API you are already aware of its object-oriented nature and you don't
> need
> > to look into the python bindings documentation all the time to predict
> how
> > each function is mapped into a method.
> >
> > What we have now is a mixture of the two models that on one hand makes
> the
> > code not look entirely pythonic and at the same time it forces developers
> > to learn how the C API was mapped into python function by function
> instead
> > of having a few simple and consistent rules.
>
> First, I can see the consistency aspect--one would simply stipulate that
>
> a) everything is a method
> and
> b) whatever is the first argument in the C binding gets to be the
> containing
> object.
>
> That would make the wrapper predictable for people familiar with other
> bindings of CL. That's valuable. On the other hand, this approach would
> (for
> example) stick all the enqueue_* functions into the CommandQueue class. I
> have
> some resistance to this, as I consider the functionality secondary to the
> existence or management of the command queue. Suppose some third party
> extension showed up that could also enqueue things--since they can't add
> methods to the pre-existing command queue, their extensions would look like
> second-class citizen. That's why I strive to keep the set of methods as
> minimal as possible. I agree that scenario itself is rather hypothetical,
> but
> it's a guideline that I based my design on.
>
> Next, I'd like to argue against the notion that the present way is
> inconsistent: any operation involving two or more objects gets to be a
> function, rather than a method.
>
> Finally, since you cited create_image: In terms of "OO-ness", one could
> also
> argue that create_image_...() should rather be the object's constructor,
> which
> would also go against the consistency cited above, but would feel very
> natural
> in a Python OO way, at least to me.
>
> In summary, it's a tradeoff. Consistency with other bindings is a virtue.
> Extensibility is another. "Pythonicity" is yet another. I'm not claiming to
> know the best tradeoff.
>
> > Andreas, I apologize for criticizing your work. I'm definitely glad and
> > grateful that you took the effort to design the bindings and implement
> > them. I'm only giving the point of view of somebody familiar with the
> > native API trying to write some code using python and finding it
> confusing
> > at times.
>
> No need to apologize. I really appreciate that you're taking the time to
> describe your point of view.
>
> Andreas
>
10 years, 2 months
get_supported_image_formats fails?
by David Garcia
It looks like function gl_get_image_formats is currently broken.
>>> tmp = cl.get_supported_image_formats(self.clctx, flags,
cl.mem_object_type.IMAGE2D)
TypeError: No to_python (by-value) converter found for C++ type:
std::vector<_cl_image_format, std::allocator<_cl_image_format> >
Cheers,
David
10 years, 2 months
Creating image formats is cumbersome
by David Garcia
Hi,
If you want to create an image you need to pass the image format you desire.
Right now image formats are set up this way:
>>> fmt = cl.ImageFormat
>>> fmt.channel_type = cl.channel_type.UNORM_INT8
>>> fmt.channel_order = cl.channel_order.RGBA
Wouldn't it be more convenient to have a constructor so that we can execute
this instead?
>>> fmt = cl.ImageFormat(cl.channel_type.UNORM_INT8, cl.channel_order.RGBA)
If you think about it, this is still rather verbose. We could put all
constants directly at global scope in the module, even if it means that we
have to keep the original CL_XXX_ prefixes to avoid collisions. That way we
could do this:
>>> fmt = cl.ImageFormat(cl.UNORM_INT8, cl.RGBA)
That is the convention that was chosen for the C++ bindings:
http://www.khronos.org/registry/cl/api/1.0/cl.hpp . I think it would be
great if the python bindings followed the same guidelines as the C++ ones,
as it would make adoption and porting easier.
I'm not familiar with the toolchain that is required to modify pyopencl but
I'm more than willing to learn and apply these changes if you agree that
they are a step in the right direction.
Cheers,
David
10 years, 2 months
Some rough edges
by David Garcia
Hi Andreas,
I've been tinkering a bit with pyopencl 0.90.4 and found a few rough edges.
dev.get_info(cl.device_info.MAX_WORK_ITEM_SIZES)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: No to_python (by-value) converter found for C++ type:
std::vector<unsigned long, std::allocator<unsigned long> >
dev.get_info(cl.device_info.MAX_WORK_GROUP_SIZE)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
pyopencl.LogicError: clGetDeviceInfo failed: invalid value
dev.get_info(cl.device_info.MAX_PARAMETER_SIZE)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
pyopencl.LogicError: clGetDeviceInfo failed: invalid value
The first error message looks like a problem in the wrapper. The other
two... I hope they don't mean that clGetDeviceInfo returned
CL_INVALID_VALUE. It is possible that the enum value is correct but the
value passed as 'param_value_size_ret' is too small. The spec says
that: "clGetDeviceInfo [...] returns CL_INVALID_VALUE if param_name is not
one of the supported values or if size in bytes specified by
param_value_size is < size of return type as specified in table 4.3"
Cheers,
David
10 years, 2 months