<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/17/2014 02:42 PM, Ashwin Srinath
wrote:<br>
</div>
<blockquote
cite="mid:CAAxipY9X6ovNNUWwCuQFH6h2NBVq=ZxZxAocEjRGVqVsYeXyhg@mail.gmail.com"
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
cite="mid:CAAxipY9X6ovNNUWwCuQFH6h2NBVq=ZxZxAocEjRGVqVsYeXyhg@mail.gmail.com"
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 moz-do-not-send="true"
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
class="">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
moz-do-not-send="true"
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 class=""><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 class="HOEnZb"><font
color="#888888"><br>
<br>
Dominic</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
-- <br>
Dominic Meiser<br>
Tech-X Corporation<br>
5621 Arapahoe Avenue<br>
Boulder, CO 80303<br>
USA<br>
Telephone: <a moz-do-not-send="true"
href="tel:303-996-2036" value="+13039962036"
target="_blank">303-996-2036</a><br>
Fax: <a moz-do-not-send="true" href="tel:303-448-7756"
value="+13034487756" target="_blank">303-448-7756</a><br>
<a moz-do-not-send="true" href="http://www.txcorp.com"
target="_blank">www.txcorp.com</a><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Dominic Meiser
Tech-X Corporation
5621 Arapahoe Avenue
Boulder, CO 80303
USA
Telephone: 303-996-2036
Fax: 303-448-7756
<a class="moz-txt-link-abbreviated" href="http://www.txcorp.com">www.txcorp.com</a></pre>
</body>
</html>