Hi Rajan, On Mon, 12 Sep 2011 16:57:30 -0500, "Yadav, Rajan1" <[email protected]> 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
pgpECcbA9AruS.pgp
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
