<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><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 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 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 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>