[petsc-dev] PETSc GPU capabilities

[Barry Smith]

On Mar 8, 2012, at 1:37 PM, Paul Mullowney wrote:

> There is some level of reusability between the matrix type data structures, especially for CSR storage. For other matrix storage formats, like ELLPACK where the performance gain can be substantial, CUSPARSE uses an opaque data structure. CUSP does not.
> 
> So, I agree that it's wrong to mix CUSP and CUSPARSE implementations. At some level I think it's wrong to be so hooked into CUSP and have all the files named after CUSP.

   That is the CUSP implementation, that is why the name is cusp.  If you do another implementation that does not use CUSP that one would not have the name CUSP in it and it would be in a different directory.

   If you extend off the CUSP implementation (that is a subclass) then that would go in a subdirectory of where the CUSP implementation is.
 

   Barry

> This is especially true since the evidence I'm gathering suggests that CUSPARSE is the better choice for SpMV and TriSolve. 
> 
> Meanwhile, CUSP is the right choice for various preconditioners, ... 
> 
> So much complexity! Perhaps, a discussion on redesign is necessary.
> 
> -Paul
> 
> 
>> On Wed, Mar 7, 2012 at 18:38, Paul Mullowney <paulm at txcorp.com> wrote:
>> I can see where this can simplify the code in aijcusp.cu.
>> 
>> However, how do you propose to let the user control whether or not to use CUSP or CUSPARSE?
>> 
>> It's different storage and different libraries, so it should be a different MatType, right? I think it's definitely wrong to have -mat_type cusp be using CUSPARSE instead of CUSP.
>>  
>> 
>> What do you mean? Look at src/mat/impls/aij/seq/umfpack/umfpack.c for comparison.
>> 
>> 
>