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 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
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, ...)