<div dir="ltr"><div>Thanks Karl!<br><br></div>Ashwin<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 19, 2014 at 9:45 AM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@iue.tuwien.ac.at" target="_blank">rupp@iue.tuwien.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ashwin,<br>
<br>
I'll add two functions returning the bare CUDA and OpenCL handles.<br>
<br>
Best regards,<br>
Karli<span class=""><br>
<br>
<br>
On 10/19/2014 03:42 PM, Ashwin Srinath wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hi everyone<br>
<br>
Just wondering what the consensus is. I'm happy to submit a PR if<br>
someone can tell me what goes where!<br>
<br>
Thanks<br>
Ashwin<br>
<br>
On 18 Oct 2014 01:46, "Karl Rupp" <<a href="mailto:rupp@iue.tuwien.ac.at" target="_blank">rupp@iue.tuwien.ac.at</a><br></span><div><div class="h5">
<mailto:<a href="mailto:rupp@iue.tuwien.ac.at" target="_blank">rupp@iue.tuwien.ac.at</a>><u></u>> wrote:<br>
<br>
    Hi,<br>
<br>
     >> > Why would we want this? The packages themselves<br>
    (CUDA/ViennaCL) only<br>
<br>
            expose<br>
            memory using these specific types. What use is it to wrap<br>
            these up in<br>
            a void * if you<br>
            just have to caste back down to use them. Isn't it better to<br>
            maintain<br>
            type-specific, and<br>
            type safe, interfaces for this stuff?<br>
<br>
            The biggest problem I faced was that there was no way to<br>
            access device<br>
            memory using petsc4py - since there is no equivalent for<br>
            VecCUSPGetArray. So returning a raw pointer may not be very<br>
            helpful<br>
            for C++/CUSP users (they already have a nice way to access<br>
            device<br>
            memory) but it would definitely make things a lot easier for<br>
            Python users.<br>
<br>
<br>
        To me it sounds like something that should be dealt with in the<br>
        library<br>
        that does the python bindings, not in PETSc itself. (...)<br>
<br>
<br>
    Unfortunately, this is not so easy: If the Python wrapper has to<br>
    take care of such a conversion, then it needs to use the *exactly<br>
    same build environment* as PETSc. The reason is that the CUSP and<br>
    ViennaCL types are C++ beasts, not having a defined ABI, so one can<br>
    run into all sorts of hard-to-debug problems when finally linking<br>
    libpetsc.so with the Python wrapper. If, however, PETSc provides<br>
    these low-level memory buffers, the Python wrapper can attach to a<br>
    well-defined ABI.<br>
<br>
    Best regards,<br>
    Karli<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br></div>