On Fri, Oct 17, 2014 at 10:45 AM, Lisandro Dalcin <[email protected]> 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.

...

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.

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? Matt

-- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.edu.sa/

4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 4332 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa

Office Phone: +966 12 808-0459

-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener