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
