[petsc-dev] Not possible to do a VecPlaceArray for veccusp

[Jose E. Roman]

> El 26 feb 2016, a las 18:31, Dominic Meiser <dmeiser at txcorp.com> 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