On Thu, 18 Jun 2015 11:44:03 +0000 <[email protected]> wrote:
> Note: This is an existence proof, not an approach. I noticed some people > getting halfway there. This gets all the way, but somebody with expert > knowledge of pyOpenCL design would be best to integrate clMath into pyOpenCL. Andreas is probably the best person to answer but he did not include "scikit-cuda" which provides bindings for cuFFT. I guess his point of view is the same for a similar issue. > Also AMD told me clAmdBlas is deprecated in favor of open source clMath on > github, so clMath is the thing to incorporate. > ClMath has a pyopencl wrapper in the distribution, but there is not a soup to > nuts example of how to use it in a purely pyOpenCL and pure Python way. Also > other features aren't wrapped. It is a good move from AMD: for the FFT part, it is an external project which is providing the bindings. > Also there is githuib clRnd as well as clFFT mentioned. I did not know this one. We did some work with the debian-science community (thanks Ghislain) to package the blas and fft part. My idea was to make them available from python. > Not clear to me where wrappers should go so that user in Python (not writing > app code in Cython),can see all of these libraries in pyOpenCL. Should > wrappers go in each package or in pyOpenCL package? As the library is C++, the python wrapper needs to be either in clMath either in a separate project. In pyOpenCL it is likely to de-stabilize pyopencl (seg-fault, library not found, ...) Cheers, Jerome _______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
