<html><body><p>Hi<br><br>Sorry for replying to this thread late - I see that most of the questions have already found an answer.<br>As Jim, I am also very happy to hear about Google's work on accelerators.<br><br>A couple of notes that caught my eye before going into the integration discussion:<br><br><font face="Courier New">> provides an open-source alternative to the CUDA runtime library.</font><br><br>Interesting: this still means that you have to go through the CUDA driver API, right?<br>I am specifically referring to what is described here:<br><a href="http://docs.nvidia.com/cuda/cuda-driver-api/#axzz42zF30dZw">http://docs.nvidia.com/cuda/cuda-driver-api/#axzz42zF30dZw</a><br><br>libomptarget's rtl library for cuda-enabled device uses the CUDA driver API directly, not the CUDA runtime library.<br><br>> <font color="#222222" face="Arial"> However, if it turns out that the needs of OpenMP are too specialized to fit well in a generic parallelism project,</font><br><br>Of course, the libomptarget interface was designed to support OpenMP, not *any* parallelism project. It is still very general, as the OpenMP programming language is, and independent of any acceleration type because of the huge multi-company and users interest in the language.<br><br><font face="Courier New">> execute data-parallel kernels written in the OpenCL or CUDA kernel languages.</font><br><br>Libomptarget does not currently have an OpenCL interface in its device-dependent RTL list. However, I am pretty sure that other companies working on OpenCL (ARM? AMD?) would be interested in having this, as well as a clang/llvm path that is capable of going from OpenMP to their native languages.<br><br><br>About integration of the two project:<br><br>- If I read Chandler's comment correctly, I do agree that we do not need to force coupling between the two libraries.<br><br>- libomptarget could add a RTL plug-in which interfaces to StreamExecutor. My question is: what does StreamExecutor do additionally from the current CUDA RTL implementation? I would be specifically interested in performance-related points here.<br>To do this, StreamExecutor would need to implement the interface that is defined between the target-agnostic part of libomptarget and the target-dependent part. What would be the interest of StreamExecutor in doing this?<br><br><br>Finally, one interesting bit about OpenMP is that it does not expose (in the language) any CUDA-like mechanisms like streams. The user can specify that certain tasks (e.g. target data-parallel tasks running on a device) can be executed asynchronously and can define dependencies between them. Under the hood, libomptarget will make extensive use of CUDA streams to satisfy dependencies living exclusively on the GPU, but the user does not get exposed to it.<br><br><br>I hope this helps bringing the discussion forward.<br><br>Thanks!<br><br>-- Carlo<br><br><br><br><img width="16" height="16" src="cid:1__=8FBBF5E4DFC603818f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for "Cownie, James H via llvm-dev" ---03/15/2016 07:41:27 AM---OK, thanks. -- Jim"><font color="#424282">"Cownie, James H via llvm-dev" ---03/15/2016 07:41:27 AM---OK, thanks. -- Jim</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">"Cownie, James H via llvm-dev" <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Chandler Carruth <chandlerc@google.com>, Jason Henline <jhen@google.com>, C Bergström <cbergstrom@pathscale.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">llvm-dev <llvm-dev@lists.llvm.org>, cfe-dev <cfe-dev@lists.llvm.org>, "openmp-dev@lists.llvm.org" <openmp-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/15/2016 07:41 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [llvm-dev] [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">"llvm-dev" <llvm-dev-bounces@lists.llvm.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><a name="_MailEndCompose"></a><font color="#1F497D" face="Verdana">OK, thanks.</font><br><font color="#1F497D" face="Verdana"> </font><br><font color="#1F497D" face="Verdana">-- Jim<br><br>James Cownie <james.h.cownie@intel.com><br>SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)</font><br><font color="#1F497D" face="Verdana">Tel: +44 117 9071438</font><br><font color="#1F497D" face="Verdana"> </font><br><b><font face="Calibri">From:</font></b><font face="Calibri"> Chandler Carruth [</font><font face="Calibri"><a href="mailto:chandlerc@google.com">mailto:chandlerc@google.com</a></font><font face="Calibri">] </font><b><font face="Calibri"><br>Sent:</font></b><font face="Calibri"> Tuesday, March 15, 2016 11:28 AM</font><b><font face="Calibri"><br>To:</font></b><font face="Calibri"> Cownie, James H <james.h.cownie@intel.com>; Jason Henline <jhen@google.com>; C Bergström <cbergstrom@pathscale.com></font><b><font face="Calibri"><br>Cc:</font></b><font face="Calibri"> llvm-dev <llvm-dev@lists.llvm.org>; cfe-dev <cfe-dev@lists.llvm.org>; openmp-dev@lists.llvm.org</font><b><font face="Calibri"><br>Subject:</font></b><font face="Calibri"> Re: [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries</font><br><font size="4" face="Times New Roman"> </font><br><font size="4" face="Times New Roman">On Tue, Mar 15, 2016 at 12:13 PM Cownie, James H <</font><a href="mailto:james.h.cownie@intel.com"><u><font size="4" color="#0000FF" face="Times New Roman">james.h.cownie@intel.com</font></u></a><font size="4" face="Times New Roman">> wrote:</font><br><a name="msg-f%3A1528866180504485379__MailEndCompos"></a><font color="#1F497D" face="Verdana">Chandler,</font><br><font color="#1F497D" face="Verdana"> </font><br><font color="#1F497D" face="Verdana">That raises a more meta-question for me, which is “Why should StreamExecutor be in LLVM at all?”</font><br><font color="#1F497D" face="Verdana"> </font><br><font color="#1F497D" face="Verdana">AFAICS, with you approach</font><p><font color="#1F497D" face="Symbol">·</font><font size="1" color="#1F497D" face="Times New Roman"> </font><font color="#1F497D" face="Verdana">It is not a runtime library whose interface the compiler needs to understand.</font><br><font size="4" face="Times New Roman">The original email pretty clearly spells out how it is specifically intended to be a target for the compiler?</font><br><font size="4" face="Times New Roman"> </font><p><font color="#1F497D" face="Symbol">·</font><font size="1" color="#1F497D" face="Times New Roman"> </font><font color="#1F497D" face="Verdana">It does not depend on any LLVM runtime libraries.</font><p><font color="#1F497D" face="Symbol">·</font><font size="1" color="#1F497D" face="Times New Roman"> </font><font color="#1F497D" face="Verdana">It is expected to be used with out-of-tree plugins.</font><br><font size="4" face="Times New Roman">Note that this doesn't mean there won't be in-tree plugins. It's analogous to how LLVM supports out-of-tree targets.</font><br><font color="#1F497D" face="Verdana"> </font><br><font color="#1F497D" face="Verdana">If I got all of that right, what connection does it have with LLVM that makes having it in the LLVM tree necessary, or an improvement over simply having it on github (or whatever your favourite open-source hosting location is)?</font><br><font size="4" face="Times New Roman">If there were nothing compiler related to it, then the argument would be much more tenuous. But I think there is a great deal of compiler relevance here.</font><p><font size="4" face="Times New Roman">---------------------------------------------------------------------<br>Intel Corporation (UK) Limited<br>Registered No. 1134945 (England)<br>Registered Office: Pipers Way, Swindon SN3 1RJ<br>VAT No: 860 2173 47</font><p><font size="4" face="Times New Roman">This e-mail and any attachments may contain confidential material for<br>the sole use of the intended recipient(s). Any review or distribution<br>by others is strictly prohibited. If you are not the intended<br>recipient, please contact the sender and delete all copies.</font><tt>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br></tt><tt><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></tt><tt><br></tt><p><p><BR>
</body></html>