[PyOpenCL] PyOpenCL integration

[Andreas Kloeckner]

Hi Rajan,

On Mon, 12 Sep 2011 16:57:30 -0500, "Yadav, Rajan1" <Rajan1.Yadav at amd.com> wrote:
> I am Rajan Yadav, a co-op at AMD, Austin. I am working towards
> developing a set of python wrappers for our existing OpenCL based FFT
> libraries. Our wrappers would be very thin and we want to make use of
> PyOpenCL to do stuff that OpenCL does in our existing libraries. For
> example, python user will himself create context and command queues
> and pass them on to our library. I am running into some problems in
> getting those PyOpenCL objects passed to our FFT library as C++
> objects which were passed to python by PyOpenCL.
> 
> My mentor Kent contacted you a few days ago regarding this
> issue. Because of some other tasks, I had to defer working on these
> wrappers.
> 
> In the mail attached, you suggested to build PyOpenCL with
> USE_SHIPPED_BOOST = False in siteconf.py file.  Also, I adjusted the
> paths for boost headers and libraries in the same file and then did
> make and make install. One problem here is that in siteconf file, the
> name of boost python library is configured as
> boost_python-gcc43-mt. No such library gets installed when followed
> the procedure at http://wiki.tiker.net/BoostInstallationHowto
> . Instead, there is libboost_python.so in $HOME/pool/lib
> directory. So, I changed boost_python-gcc43-mt to boost_python in
> siteconf and moved forward, hoping that is right. Please correct me if
> its not.

That's correct. That default will also be changed in the next version of
PyOpenCL.

> The next suggestion that you gave was to include the header
> wrap_cl.hpp in our code. This implies that I should now be able to
> allocate the object of type pyopencl::context which I am able to. Now,
> we have a function in C++ that expects an object of type
> pyopencl::context along with bunch of other arguments. If we omit this
> pyopencl::context type argument, python is able call the c++ function
> successfully. But when python passes the "Context" type object to this
> function, there is a runtime ArgumentError:
> 
>   File "pointers.py", line 49, in <module>
>     print "pyFFT,clAmdFftCreateDefaultPlan() = ", pyFFT.clAmdFftCreateDefaultPlan(plHandle, ctx1, i, 100)
> Boost.Python.ArgumentError: Python argument types in
>     pyFFT.clAmdFftCreateDefaultPlan(pyClAmdFftPlanHandle, Context, clAmdFftDim, int)
> did not match C++ signature:
>     clAmdFftCreateDefaultPlan(pyClAmdFftPlanHandle, pyopencl::context, clAmdFftDim, int)
> 
> From what I understand, somewhere between python and our C++ code, the
> interface doesn't understand that "Context" type object in python is
> same as "pyopencl::context" type object and this where the problem
> arises. In your previous email you also said "('class buffer' is
> likely the one you need.)". I did not understand this point. Do
> pyopencl objects use different kind of memory allocation ? Why and at
> what point will I need buffer object in our wrappers ?

When you say 'Context', that object (let's call it 'obj') satisfies
'isinstance(obj, pyopencl.Context)'?

Another idea: Check using the 'ldd' tool whether the boost python
libraries used by your package and pyopencl are really the same:

Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyopencl
>>> pyopencl._cl.__file__
'/home/andreas/src/pyopencl/pyopencl/_cl.so'
>>> 
~ ldd /home/andreas/src/pyopencl/pyopencl/_cl.so
linux-vdso.so.1 =>  (0x00007fffadbbf000)
libboost_python-py26.so.1.46.1 => /usr/lib/libboost_python-py26.so.1.46.1 (0x00007f18690db000)
libOpenCL.so.1 => /home/andreas/pack/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/libOpenCL.so.1 (0x00007f1868ed5000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f1868bcc000)
libm.so.6 => /lib/libm.so.6 (0x00007f186894a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1868733000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1868517000)
libc.so.6 => /lib/libc.so.6 (0x00007f1868194000)
libutil.so.1 => /lib/libutil.so.1 (0x00007f1867f90000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f1867d8c000)
librt.so.1 => /lib/librt.so.1 (0x00007f1867b84000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1869653000)

(On Windows, Dependency Walker does something similar.)

Next--and probably the best idea by looking at your function
signature--try accepting a reference to the context instead of a
by-value call.

Hope some of this helps,
Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.tiker.net/pipermail/pyopencl/attachments/20110912/fad3b4fe/attachment.pgp>