[petsc-dev] PETSc GPU capabilities

Paul Mullowney paulm at txcorp.com
Thu Mar 8 13:26:15 CST 2012


Agreed that -use_cusparse should not exist. I did it so that it was easy 
to switch between CUSP and CUSPARSE so that I could gather sufficient 
data to make a sensible choice of which library to use. As I said in 
previous emails, CUSPARSE is appears to be very compelling for SpMV. 
Moreover, it is the only option for TriSolve aside from my own 
implementation.
> -use_cusparse should not exist. There should also never be 
> PetscOptions calls that don't use a prefix. In all but extreme 
> circumstances, PetscOptionsGetXX() should not be used in library code, 
> all options should have help strings and be processed in the 
> XSetFromOptions_IMPL() routine.
>
> 1. txpetscgpu hides all type conversions and dispatch choices 
> internally. Then there could be one PETSc interface file.
>
If this choice, then a new subdirectory
src/mat/impls/aij/seq/seqgpu (or some other name),

with
-mat_type txcusp
-mat_type txcusparse

> 2. There are two (or more) PETSc Mat implementations. Some may make 
> calls into txpetscgpu.
>
>     This multiply function will invoke CUSPARSE functions if
>     -use_cusparse is given at the command line. This can be removed if
>     we allow for -mat_type cusparse?
>
>
If we choose this option, will
-mat_type cusp
allow one to use the CUSPARSE TriSolve for ILU or ICC?

Alternatively, if one uses
-mat_type cusparse
for SpMV, will one be able to use the CUSP AMG and Poly preconditioners?

Since I am new to this, what would PETSc developers like to see?

One more wrinkle. Given the naming conventions, should the vector types be
-vec_type thrust
instead of
-vec_type cusp

The vectors only rely on Thrust capabilities at the moment.

-Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120308/cdfa2e62/attachment.html>


More information about the petsc-dev mailing list