PyOpenCL September 2009

pyopencl@tiker.net

13 participants
33 discussions

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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 10 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, 10 months

Hacking towards 0.91

by Andreas Klöckner

Hi all, I just had a pretty productive hack session on PyOpenCL that I hope will give us a good 0.91 release in a few days. In the meantime, here's what happened: http://documen.tician.de/pyopencl/misc.html#version-0-91 You can get the changes from git. Andreas

10 years, 10 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

PyOpenCL September 2009