> 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 <[email protected]> wrote: > 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 > >
