The alternative would be to use raw cuda pointers instead of cusp
arrays for GPU memory in VecCUSP. That would be a fairly
significant undertaking (certainly more than the 2-3 weeks Karli
is estimating for getting the ViennaCL cuda backend in).
Do you mean creating a new class VECCUDA in addition to VECCUSP and
VECVIENNACL? This could be a solution for us. It would mean maybe refactoring
MATAIJCUSPARSE to work with these new Vecs?
I prefer to replace VECCUSP with e.g. VECCUDA (and eventually also
rename VECCUSPARSE to VECCUDA to have a unified naming for all the
things provided natively with the CUDA SDK) in order to reduce external
dependencies. CUSP will provide matrices, preconditioners, etc. as
before, but is only optional and thus less likely to cause installation
troubles. Supporting VECCUSP and VECCUDA next to each other is going to
be too much code duplication without any benefit.
Even if we do provide VECCUDA, I still dislike the fact that we would
have to maintain essentially the same code twice: One for CUDA, one for
OpenCL/ViennaCL. With the ViennaCL bindings providing OpenMP and CUDA
support soon, this also duplicates functionality. A possible 'fix' is to
just use ViennaCL for CUDA+OpenCL+OpenMP and thus only maintain a single
PETSc plugin for all three. However, I'm certainly too biased to be
taken seriously here.
>
> If there is interest we can help in adding this stuff.
What are your time constraints?
Best regards,
Karli
