> On Feb 2, 2018, at 11:10 PM, Karl Rupp <r...@iue.tuwien.ac.at> 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

Reply via email to