[petsc-dev] PETSc GPU capabilities
Jed Brown
jedbrown at mcs.anl.gov
Thu Mar 8 13:03:26 CST 2012
On Thu, Mar 8, 2012 at 12:54, Paul Mullowney <paulm at txcorp.com> wrote:
> I put it in there because it was really, really easy to use the CUSP CSR
> data structure in the CUSPARSE TriSolve. CUSP does not have a TriSolve.
> However, CUSPARSE also supports a TriSolve based on the ELLPACK (and Hybrid
> format). This is an opaque data structure again, so it may be wise to pull
> CUSPARSE stuff out of aijcusp.cu and into an aijcusparse.cu? Does this
> seem sensible?
>
> Then, I suppose one can have
> -mat_type cusparse
> and thus remove -use_cusparse.
>
-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.
> As for SpMV, the calls to CUSPARSE API are contained within my txpetscgpu
> package and is fairly removed from PETSc. In fact, all you see in PETSc is
> ierr = cuspstruct->mat->multiply(xarray, yarray);
>
There are basically two choices.
1. txpetscgpu hides all type conversions and dispatch choices internally.
Then there could be one PETSc interface file.
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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120308/b12ca20e/attachment.html>
More information about the petsc-dev
mailing list