[petsc-dev] Backend independent VecGetArray for GPUs

[Barry Smith]

  So in the compiled C/C++ world 

>> VecCUDAGetArray()
>>  VecOpenCLGetArray()

   would essentially call VecCUSPGetArray() or VecViennaCLGetArray() and then pull the “raw” pointer out of that beasty?   But  we really don’t need VecCUDAGetArray() and VecOpenCLGetArray() in the C/C++ world since the user can simply call VecCUSPGetArray() or VecViennaCLGetArray() and then use the CUSP or ViennaCL specific way of pulling out the “raw” CUSP or OpenCL pointer, is this correct?

 Now moving onto Python, presumably CUSP and ViennaCL do not have python bindings? (Why the heck not?) And thus there is no “natural” thing for VecCUSPGetArray() or VecViennaCLGetArray() to return in Python? 

  So, the conclusion is that since CUSP and ViennaCL do not have Python bindings (why the heck not?) this means PETSc needs to extend its API even in C/C++ land? Or would VecCUDAGetArray() and VecOpenCLGetArray() only exist in Python? An alternative is to introduce into Python a CUSP array class and a Vienna CL array class that only does one thing: provides a way to pull out the raw CUDA or OpenCL pointer, then in Python the user would do the same thing as C/C++, first pull out the CUSP/ViennaCL pointer with VecCUSPGetArray() or VecViennaCLGetArray() and then pull out the raw pointer using the little “wrapper class"?

One the naming: It should be VecCUSPGetCUDAArray() and VecViennaCLGetOpenCLArray() since the second part of the name is associated with the sub class of the first part of the name (e.g. VecCUSP is a subclass of Vec) Since there is no VecOpenCL subclass, for example, it cannot be VecOpenCLGetArray()

  What am I missing?

  Barry



> On Oct 17, 2014, at 11:40 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Karl Rupp <rupp at iue.tuwien.ac.at> writes:
>> If this should be provided, then the right names were
>>  VecCUDAGetArray()
>>  VecOpenCLGetArray()
>> The former returns an object of type PetscScalar* and the latter an 
>> object of type cl_mem. Because one is stuck with two incompatible 
>> pointer types here, I'd suggest not to provide a single interface at the 
>> expense of giving up type safety. 
> 
> Agreed.
> 
> Does cl_mem have a "null"?
> 
>> Also, even if one gives up type safety, one would immediately have to
>> switch-case into a backend-specific implementation again, so there's
>> little value in a common interface.
> 
> It's useful to have a non-error path for calling.