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>
