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
