<p dir="ltr">Hi Karli,</p>
<p dir="ltr">Lazy initialization mechanism looks good. But the problem is that the initialize will still happen twice if we create Vec in both our Petsc instances.</p>
<p dir="ltr">Can we have an option for Petsc in which we can specify whether cudaSetDevice should be run by Petsc or not?</p>
<p dir="ltr">Thanks,<br>
Harshad</p>
<div class="gmail_quote">On Jan 14, 2014 12:35 PM, "Karl Rupp" <<a href="mailto:rupp@mcs.anl.gov">rupp@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Harshad,<br>
<br>
> Sometime back we talked about an interface which could handle other<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
libraries calling cudaSetDevice simultaneously with PETSc. For example,<br>
in our case 2 different instances of PETSc calling cudaSetDevice.<br>
<br>
 >Sure, but how will we actually share the device between libraries?  What<br>
 >if the other library was not PETSc, but something else, and they also<br>
 >called cudaSetDevice, but with a different default mapping strategy?<br>
<br>
 >We need an interface that handles this case.<br>
<br>
Do we already have any solution for this? If not, can we start looking<br>
at this case?<br>
</blockquote>
<br>
I offered to provide a lazy initialization mechanism in order to be able to deal with such cases - this is still on my todo-list. Due to other obligations I couldn't find the time to implement this yet, but finally things are getting better so that I can provide the changes soon.<br>

<br>
Best regards,<br>
Karli<br>
<br>
</blockquote></div>