[petsc-dev] Backend independent VecGetArray for GPUs

[Ashwin Srinath]

> Why would we want this? The packages themselves (CUDA/ViennaCL) only
expose
memory using these specific types. What use is it to wrap these up in a
void * if you
just have to caste back down to use them. Isn't it better to maintain
type-specific, and
type safe, interfaces for this stuff?

The biggest problem I faced was that there was no way to access device
memory using petsc4py - since there is no equivalent for VecCUSPGetArray.
So returning a raw pointer may not be very helpful for C++/CUSP users (they
already have a nice way to access device memory) but it would definitely
make things a lot easier for Python users.

Thanks!

On Fri, Oct 17, 2014 at 12:09 PM, Dominic Meiser <dmeiser at txcorp.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20141017/04d3267f/attachment.html>