> On Feb 2, 2018, at 11:10 PM, Karl Rupp <[email protected]> wrote: > > Hey, > >> I'm am totally confused by >> 1) the existence of veccuda.py > > if I remember correctly, its purpose is to make sure that one of the GPU > backends is enabled if a user configures --with-cuda. > > >> 2) the fact that veccuda.py depends on some packages but is not a package >> and is not in packages/ > > I don't know this. In any case, veccuda.py is an artifact of a too rigid GPU > backend implementation and should be removed once the GPU backend > implementation is fixed. > > >> 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). > > >> Can we get rid of the veccuda.py and the PETSC_HAVE_VECCUDA flag and just >> always have the VECCUDA type if cuda is available? > > Yes, that's possible after some refactorization. > > >> 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? > 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 ;) > > Best regards, > Karli
