> El 26 feb 2016, a las 18:31, Dominic Meiser <[email protected]> escribió: > > On Fri, Feb 26, 2016 at 02:49:39PM +0100, Karl Rupp wrote: >> >>>> 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. > > That makes sense. At the Vec level we should be using a low > level construct (i.e. cuda raw pointers) because clients can > always provide raw pointers and they know how to consume them > (e.g. if they want to use cusp vectors on their end). > >> >> 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. > > I agree with this in principle. Perhaps it's time to consolidate > the cuda/cusp/cusparse/opencl efforts. Note however that > MATAIJCUSPARSE provides capabilities that won't be available > right away with ViennaCL (e.g. multi-GPU block Jacobi and ASM > preconditioners).
I like the idea of having separate VECCUDA and VECVIENNACL, because it is possible to implement VECCUDA without dependence on a C++ compiler (only the CUDA compiler). If you want, we can prepare a rough initial implementation of VECCUDA in the next days, and we can later discuss what to keep/discard. Karl: regarding the time constraints, our idea is to present something at a conference this summer, and deadlines are approaching. > > Cheers, > Dominic > > >> >>> >>> If there is interest we can help in adding this stuff. >> >> What are your time constraints? >> >> Best regards, >> Karli >> >> > > -- > Dominic Meiser > Tech-X Corporation - 5621 Arapahoe Avenue - Boulder, CO 80303
