<p dir="ltr">What about having threads and OpenCL in the same application?</p>
<div class="gmail_quote">On Apr 12, 2013 5:31 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">
Hey,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do we want to have a concept, of which opencl, cuda, and threadcomm are<br>
instantiations? -device_opencl_view?<br>
</blockquote>
<br>
nice idea, sounds a bit like the 'framework' concept in Mac OS. On the other hand, the only thing that is common to OpenCL, CUDA, and threadcomm is that they aim at parallelism for a single process on a single node (we can safely ignore fake environments such as vSMP since we have MPI already).<br>

<br>
Ignoring all existing code for CUDA and OpenCL in PETSc: it might work to set up a local communicator concept (i.e. threadcomm extended to CUDA and OpenCL) in order to deal with the parallelism. To do so, threadcomm would need to be supplemented by an 'offloaded memory' model and should rather be called 'localcomm' then (this is supposed to be 'part 2' of my yet-to-be-written-and-improved ideas for a unification of these approaches). Resulting flags:<br>

  -localcomm_threads_view<br>
  -localcomm_opencl_view<br>
  -localcomm_cuda_view<br>
<br>
Best regards,<br>
Karli<br>
<br>
</blockquote></div>