[petsc-dev] Backend independent VecGetArray for GPUs

[Dominic Meiser]

On 10/17/2014 09:45 AM, Lisandro Dalcin wrote:
> On 17 October 2014 17:54, Dominic Meiser <dmeiser at txcorp.com> wrote:
>> Hi Ashwin,
>>
>> Are you suggesting that `VecGetGPUArray*`  be added to the `Vec` interface?
>> That might be problematic because these methods only makes sense for GPU
>> vectors. The interface of `Vec` would then be tied to the PETSc
>> configuration.
>>
> These methods could be always available simply generate an error for
> non-GPU vector types.
That's a possible approach. Barry, Jed, what's the preferred way of 
doing this? Make base class interface wider or subtyping via compose and 
query?
>
>> An alternative might be to compose the various `VecCUSPGetArray` and related
>> methods with `Vec` objects. You could then query these methods and use them
>> if available (and handle absence of the methods if needed, e.g. throw an
>> exception). This would be easy to add.
>>
> Yes, however note that what we really need is a backend-independent
> way to get the RAW pointer to the GPU buffers. Right now we have calls
> to get the CUSP or ViennaCL array, to handle them you need C++ and
> depend on CUDA/OpenCL at compile-time.
>
>
In what sense should it be backend-independent? The method name should 
be independent of the backend? Or the presence of the method should be 
backend independent?

I don't see what your gaining by having the methods in Vec. You still 
need to handle the error that occurs if you're dealing with a non-GPU 
vector and you still have to know the vector type in order to interpret 
the return value (device pointer vs OpenCL buffer).

Dominic

-- 
Dominic Meiser
Tech-X Corporation
5621 Arapahoe Avenue
Boulder, CO 80303
USA
Telephone: 303-996-2036
Fax: 303-448-7756
www.txcorp.com