[petsc-dev] refactoring petsccusp.h needed

[Barry Smith]

On Mar 8, 2013, at 4:07 PM, Paul Mullowney <paulm at txcorp.com> wrote:

> Not quite. I want to expose a PetscScalar * rather than a CUSPARRAY *.

   Well it cannot expose a PetscScalar since PetscScalar lives in CPU memory space, not GPU memory space. 

    Do you mean the raw pointer inside a CUSPARRAY array? It would be fine to have functions to return those whose prototypes go in petsccusp.h

   Barry



>>> 1) I would like a public method that exposes the GPU device pointers to the user. For example, we have VecGetArrayRead(). But, this gives a CPU pointer (which in turn causes a memcpy from CPU to GPU).  We need something that returns the GPU device pointer. This is useful for embedded PETSc solves in external apps that want to use the GPU.
>>   Yup. Are these not just
>> #undef __FUNCT__
>> #define __FUNCT__ "VecCUSPGetArrayReadWrite"
>> PETSC_STATIC_INLINE PetscErrorCode VecCUSPGetArrayReadWrite(Vec v, CUSPARRAY **a)
>> {
>>   PetscErrorCode ierr;
>> 
>>   PetscFunctionBegin;
>>   *a   = 0;
>>   ierr = VecCUSPCopyToGPU(v);CHKERRQ(ierr);
>>   *a   = ((Vec_CUSP*)v->spptr)->GPUarray;
>>   PetscFunctionReturn(0);
>> }
>> 
>> and friends? Just make them not static inline and put the prototypes for them in petsccusp.h  The function call cost can be lived with.
>> 
>> (You would make them not static inline because we don't want Vec_CUSP to be public.)
>> 
>> 
>> Thanks
>> 
>>     Barry
>> 
>>    Barry
>> 
>>> 2) As for other things. I have a patch for ICC that I'm nearly finished with. After that, I'm going to try to harden the other CUSP preconditioners so that they work with the CUSP and CUSPARSE classes.
>>> 
>>> -Paul
>>>>    Do you think you can make that change and anything else that needs doing before the release?
>>>> 
>>>>    Thanks
>>>>     Barry
>>>> 
>