On Thu, 18 Jun 2015 11:44:03 +0000
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
Also there is githuib clRnd as well as clFFT
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
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, ...)