Hi Kent, On Tue, 2 Aug 2011 00:46:11 -0500, "Knox, Kent" <[email protected]> wrote: > Thank you for the link to the mailing list; I'll direct future > inquiries there.
I've cc'd the list, hope you don't mind. I'm sure many on the list would
be quite interested in your wrappers.
> Our co-op is having difficulties in getting the
> OpenCL context that is created within pyopencl to be successfully
> passed to our FFT wrapper. Would you know of any reason that this
> would fail? We will investigate the use of pyopencl's array class for
> use in our wrapper. I think we naively assumed that cl_mem buffer
> objects were the appropriate choice.
If you look at src/wrapper/wrap_cl.hpp, you'll see that PyOpenCL uses a
bunch of thin, object-oriented C++ wrappers around CL's objects which
are then exposed to Python. So your wrapper should be prepared to
receive those. ('class buffer' is likely the one you need.)
There are two mild restrictions here:
1) Your wrapper needs access to that header. For now, it is not
installed along with PyOpenCL, but that can easily be changed. (but that
wouldn't be necessary if the wrapper were to be part of PyOpenCL)
2) If you build PyOpenCL in 'shipped-boost' mode, then only code within
PyOpenCL's shared object (pyopencl/_cl.so) will be able to accept
arguments of the above types at the C++ level.
> Our FFT and BLAS libraries up to version 1.2 require an OpenCL 1.1
> runtime. We are working in our 1.4 release to support OpenCL 1.0
> devices too, which should include other vendors.
Great! (Not sure if that's what you're referring to, but Nvidia's 280.x
drivers actually implement 1.1.)
Hope this helps,
Andreas
pgpOxWbCjNO8q.pgp
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
