[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