<p dir="ltr">Thanks, Domomic </p>
<p dir="ltr">To be honest, I'm not sure where it would be appropriate. I'm just hoping to see the functionality *somewhere* :)</p>
<div class="gmail_quote">On 17 Oct 2014 16:02, "Dominic Meiser" <<a href="mailto:dmeiser@txcorp.com">dmeiser@txcorp.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 10/17/2014 02:42 PM, Ashwin Srinath
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">> Why would we want this? The packages
themselves (CUDA/ViennaCL) only expose
<div>memory using these specific types. What use is it to wrap
these up in a void * if you</div>
<div>just have to caste back down to use them. Isn't it better
to maintain type-specific, and</div>
<div>type safe, interfaces for this stuff?<br>
<br>
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.<br>
</div>
</div>
</blockquote>
<br>
To me it sounds like something that should be dealt with in the
library that does the python bindings, not in PETSc itself. For
example, it would be easy to write a wrapper functions like the
following:<br>
<br>
void *getDevicePtr(Vec v)<br>
{<br>
void *ptr;<br>
<br>
/* Use VecCUSPGetArray* or VecViennaCLGetArray* to obtain device
ptr */<br>
<br>
return ptr;<br>
}<br>
<br>
void releaseDevicePtr(Vec v, void *ptr)<br>
{<br>
/* Vec type specific code to release the pointer */<br>
}<br>
<br>
What do we gain by having these wrappers in PETSc rather than in a
separate library?<br>
<br>
Cheers,<br>
Dominic<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thanks!<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 17, 2014 at 12:09 PM,
Dominic Meiser <span dir="ltr"><<a href="mailto:dmeiser@txcorp.com" target="_blank">dmeiser@txcorp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 10/17/2014 09:45 AM, Lisandro Dalcin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17 October 2014 17:54, Dominic Meiser <<a href="mailto:dmeiser@txcorp.com" target="_blank">dmeiser@txcorp.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Ashwin,<br>
<br>
Are you suggesting that `VecGetGPUArray*` be added to
the `Vec` interface?<br>
That might be problematic because these methods only
makes sense for GPU<br>
vectors. The interface of `Vec` would then be tied to
the PETSc<br>
configuration.<br>
<br>
</blockquote>
These methods could be always available simply generate
an error for<br>
non-GPU vector types.<br>
</blockquote>
</span>
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?<span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
An alternative might be to compose the various
`VecCUSPGetArray` and related<br>
methods with `Vec` objects. You could then query these
methods and use them<br>
if available (and handle absence of the methods if
needed, e.g. throw an<br>
exception). This would be easy to add.<br>
<br>
</blockquote>
Yes, however note that what we really need is a
backend-independent<br>
way to get the RAW pointer to the GPU buffers. Right now
we have calls<br>
to get the CUSP or ViennaCL array, to handle them you
need C++ and<br>
depend on CUDA/OpenCL at compile-time.<br>
<br>
<br>
</blockquote>
</span>
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?<br>
<br>
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).<span><font color="#888888"><br>
<br>
Dominic</font></span>
<div>
<div><br>
<br>
-- <br>
Dominic Meiser<br>
Tech-X Corporation<br>
5621 Arapahoe Avenue<br>
Boulder, CO 80303<br>
USA<br>
Telephone: <a href="tel:303-996-2036" value="+13039962036" target="_blank">303-996-2036</a><br>
Fax: <a href="tel:303-448-7756" value="+13034487756" target="_blank">303-448-7756</a><br>
<a href="http://www.txcorp.com" target="_blank">www.txcorp.com</a><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre cols="72">--
Dominic Meiser
Tech-X Corporation
5621 Arapahoe Avenue
Boulder, CO 80303
USA
Telephone: <a href="tel:303-996-2036" value="+13039962036" target="_blank">303-996-2036</a>
Fax: <a href="tel:303-448-7756" value="+13034487756" target="_blank">303-448-7756</a>
<a href="http://www.txcorp.com" target="_blank">www.txcorp.com</a></pre>
</div>
</blockquote></div>