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. 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. I'm not an expert on the PETSc object model so hopefully somebody else can comment on whether this would be an idiomatic PETSc solution. Cheers, Dominic On 10/17/2014 08:21 AM, Ashwin Srinath wrote:
Hello, petsc-dev
When working with petsc4py, I realized that there was no way to access the underlying device memory. The routine that PETSc provides is VecCUSPGetArrayRead/Write, which of course, makes no sense in Python.
So I wrote a petsc4py extension that extracts and returns the raw device pointer from the underlying CUSP array. With this raw pointer, I'm able to construct a PyCUDA GPUArray, and apply my own kernels to the underlying buffers. My code is available here: https://github.com/ashwinsrnth/petsc-pycuda
After discussion with Lisandro Dalcin, I think that it might be a good idea for PETSc to provide a routine `VecGetGPUArray` (in place of or in addition to the current `VecCUSPGetArray`) which returns a raw pointer to device memory, and lets the user decide what to do with it.
Do you think this can fit in to PETSc? If so, I already have an implementation, but can use help with the interface.
Thank you Ashwin
-- Dominic Meiser Tech-X Corporation 5621 Arapahoe Avenue Boulder, CO 80303 USA Telephone: 303-996-2036 Fax: 303-448-7756 www.txcorp.com