Thanks. I'll try to be patient.
> On Feb 2, 2018, at 11:28 PM, Karl Rupp <[email protected]> wrote: > > >>>> Why can't the VECCUDA type coexist with the VECCUSP or VECVIENNACL types? >>>> If it can't coexist, can the code be reworked to allow it to coexist? >>> >>> Currently it can't coexist because some variables are conditionally >>> compiled and may be multiply defined (e.g. spptr). >> Hmm, I don't think so. The use of spprt shouldn't mean there cannot be >> both VECCUDA and VECCUSP at the same time (with different vectors obviously). > > There is no fundamental reason why it can't work. The relevant GPU code just > hasn't been cleaned up yet. > > Currently we have in vecimpl.h: > > #if defined(PETSC_HAVE_CUSP) > PetscCUSPFlag valid_GPU_array; /* indicates where the most > recently modified vector data is (GPU or CPU) */ > void *spptr; /* if we're using CUSP, then this is the > special pointer to the array on the GPU */ > #elif defined(PETSC_HAVE_VIENNACL) > PetscViennaCLFlag valid_GPU_array; /* indicates where the most > recently modified vector data is (GPU or CPU) */ > void *spptr; /* if we're using ViennaCL, then this is the > special pointer to the array on the GPU */ > #elif defined(PETSC_HAVE_VECCUDA) > PetscCUDAFlag valid_GPU_array; /* indicates where the most > recently modified vector data is (GPU or CPU) */ > void *spptr; /* if we're using CUDA, then this is the > special pointer to the array on the GPU */ > #endif > > > Words can't tell how ugly this is. Fixing the spptr-thing is trivial, > valid_GPU_array requires a bit more work to achieve consistent behavior > across multiple different GPU vector types. > > >>>> I'm willing to do the refactorization and simplification but I need to >>>> know there is not some secret reason for these complications. >>> >>> Unless you have to deliver something specific within the next few days, >>> I'll (finally!) do it next week together with getting rid of VECCUSP. >> So are we giving up on CUSP? And just using CUDA directly and ViennaCL? > > We don't need both VECCUDA and VECCUSP. VECCUDA does not require an external > library (part of the CUDA SDK!) and is at least as fast as VECCUSP, so the > latter is obsolete (feature-wise they are the same). > > However, I'm not saying that we give up on CUSP completely. CUSP's SA-AMG > preconditioner is still useful. It just doesn't need a separate VECCUSP > backend to operate (just like e.g. Hypre doesn't need a separate VECHYPRE). > > >>> These two steps should be done concurrently to avoid needless work. >> There is no hurry; except I hate ugliness hanging around once I see it ;( >> It makes my skin itch, just knowing it exists ;) > > Pain relief is on the way! ;-) > > Best regards, > Karli
