On 10/17/2014 09:45 AM, Lisandro Dalcin wrote:
On 17 October 2014 17:54, Dominic Meiser <[email protected]> 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
