clMathLibraries/clSPARSE

Complex matrices

zsszatmari opened this issue · 4 comments

Hi! Any love for complex numbers? I am most interested in matrix-vector multiplication at the time.

kknox commented

Unfortunately, we do not support complex arithmetic at this time; only single and double. I'll make note of the need/request, but i can not comment on when we would be able to productize.

Given how this feature request is 2,5 years old, I take it this feature will not be implemented. I was looking for a sparse linear system solver, specifically a tri-diagonal solver. There is an analysis software I'm porting from CUDA to OpenCL and it's using cusparseZgtsv and I currently lack the assets to implement:

  1. Complex support for matrices and vectors alike.
  2. Understand the trickery imbued into tri-diagonal solvers and implement it in a sensible way.
  3. Write Vcpkg support for easy deployment on Windows.

The latter I might do just for kicks, having done the OpenCL SDK, clFFT and clBLAS, should be a day worth of my time to cook up support.

As a sidenote: are ANY of the clMath libraries alive? Most of them have not seen contributions in years. Is it allowed to disclose the size of the 1st party team maintaining these libraries? If time is less pressing I am not against contributing to projects that I use, but currently I cannot make it happen. It's just strange noone with the required assets have come across the need of complex matrices.

All the clMathLibraries projects are in inactive state, with different projects in it getting very occasional bug fix work and some maintenance operation at varying frequencies. I don't have info on if these projects will become active again.

We have plans for producing new libraries for supporting sparse solvers on rocm platform, along the lines of other libraries like rocFFT and rocBLAS. They will become public when at beta ready state.

Thanks @bragadeesh for the clarification. It is rare to get definite "negative" statement upon request. Will rocFFT and rocBLAS be OpenCL based or HCC based? (Meaning, will it be cross-vendor or not?)

I only ask, cause should I be thinking about also implementing a wrapper atop cuFFT and rocFFT? NVIDIA having (finally) upstreamed 1.2 implementation, it kinda sucks that clFFT et al become inactive.