<div dir="ltr">Jason,<div><br></div><div>It looks a cool thought on providing high-level interface for CUDA-based development. By far, my understanding is that the StreamExecutor is designed as an abstract runtime layer of target architecture for offloading, still requiring the target specific code from the user. This is something that contradicts the PPM in my understanding: the abstraction of the programming itself. To make the parallel: you provide an inline assembly to enable a user with best performance/flexibility while OpenMP is rather a Fortran compiler that gives abstraction of machine at all. This I would name the biggest difference between the projects. Am I right?</div><div><br></div><div>The document you refers to is published a year ago and there was a significant progress since then, with prototype compiler implemented at <a href="https://github.com/clang-omp">https://github.com/clang-omp</a>. The implementation supports NVIDIA and x86 targets, providing an abstraction of the target platform. There are other parties contributed to the design, yet we will see open source contributions from them. Nevertheless, I can say that the design was thoroughly reviewed by them and it is approved by the full list of authors - hence, their targets are satisfied also. As per the design document, the abstraction layer is the libomptarget library supposed to dispatch different target binaries at runtime. Along with dispatching the library keeps track of all data mapping between the host and all target devices, hiding this from the user and thus removes the burden of bookkeeping. This can be a good point for the StreamExecutor to integrate its interface. Still we need to review both sides: the libomptarget interface provided to the compiler and the StreamExecutor internal interfaces. <br></div><div><br></div><div><p class="MsoNormal" style="line-height:14.65pt;background-image:initial;background-repeat:initial"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> </span><span lang="EN-GB" style="font-size:10pt;font-family:Arial,sans-serif">While the OpenMP model provides the convenience of allowing the author to write their kernel code in standard C/C++, the StreamExecutor model allows for the use of any kernel language (e.g. CUDA C++ or OpenCL C). This lets authors use platform-specific features that are only present in platform-specific kernel definition languages.</span><span lang="EN-GB"></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><span lang="EN-GB"></span></p>
<p class="MsoNormal">Per my understanding, the OpenMP standard allows calling of functions in target regions. Those functions can be generated for target either by the compiler, where user annotate appropriate functions with "#pragma omp declare target". But it also allows using of functions added to the target binaries in any other way. For example, on Xeon PHI platform one can use any shared library that is put on the device beforehand. As for the GPU and other targets – binaries obtained from other compilers/build tools should be passed to the target image link explicitly. </p><p class="MsoNormal"><br></p><p class="MsoNormal">The OpenMP programming model was aimed the program is written once, and can be compiled with many compilers for multi-targets, in addition, with the same compiler it can be compiled in serial mode. This fits well for complex build systems and provides support to number of targets with no additional interference with build scripts. My understanding is that the StreamExecutor requires different targets to be built separately and thereafter put together to allow offloading. </p><p class="MsoNormal"> </p><p class="MsoNormal">I see some other differences in programming model as well, for example, the executor project you referred to supports C++ only. Is there any plans to support plain C and Fortran? I would suggest we do a more analysis to extend the existing library for support StreamExecutor.</p><p class="MsoNormal"><br></p><p class="MsoNormal">To collaborate is always a plus and having more interested parties is beneficial both ways. I would like to start from the interfaces description and review. The interface of the libomptarget (both compiler side and the target RTL) are in the document. Could you prepare a small overview of the (perhaps, supposed) StreamExecutor internal interfaces with CUDA and OpenCL so that we can derive key common points of abstraction and try to map them to libomptarget interface?</p><p class="MsoNormal"><br></p><p class="MsoNormal">Regards,</p><p class="MsoNormal">Sergos</p><p class="MsoNormal">Intel Compiler Team</p><p class="MsoNormal"><br></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 8:50 PM, Jason Henline via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I think it would be great if StreamExecutor could use liboffload to perform its offloading under the hood. Right now offloading is handled in StreamExecutor using platform plugins, so I think it could be very natural for us to write a plugin which basically forwards to liboffload. If that worked out, we could delete our current plugins and depend only on those based on liboffload, and then all the offloading code would be unified. Then, just as James said, StreamExecutor would provide a nice C++ interface on top of liboffload, and liboffload could continue to support OpenMP directly.</div><div><br></div><div>In this plan, I think it would make sense to move liboffload to the new project being proposed by this RFC, and hopefully that would also make liboffload more usable as a stand-alone project. Before moving forward with any of these plans, I think it is right to wait to hear what IBM thinks.</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 14, 2016 at 10:14 AM C Bergström <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">/* ignorable rant */<br>
I've publicly advocated it shouldn't have been there in the 1st place.<br>
I have been quite vocal the work wasn't for everyone else to pay, but<br>
should have been part of the initial design. (Basically getting it<br>
right the 1st time - instead of forcing someone else to wade through a<br>
bunch of cmake)<br>
<br>
On Tue, Mar 15, 2016 at 1:10 AM, Cownie, James H<br>
<<a href="mailto:james.h.cownie@intel.com" target="_blank">james.h.cownie@intel.com</a>> wrote:<br>
>> I'd support some of Jame's comments if liboffload wasn't glued to OMP as it is now.<br>
><br>
> I certainly have no objection to moving liboffload elsewhere if that makes it more useful to people.<br>
> There is no real "glue" holding it there; it simply ended up in the OpenMP directory structure because that<br>
> was an easy place to put it, not because that's the optimal place for it.<br>
><br>
> To some extent it has stayed there because no-one has put in any effort to do the work to move it.<br>
><br>
> -- Jim<br>
><br>
> James Cownie <<a href="mailto:james.h.cownie@intel.com" target="_blank">james.h.cownie@intel.com</a>><br>
> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)<br>
> Tel: +44 117 9071438<br>
><br>
> -----Original Message-----<br>
> From: C Bergström [mailto:<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>]<br>
> Sent: Monday, March 14, 2016 5:01 PM<br>
> To: Cownie, James H <<a href="mailto:james.h.cownie@intel.com" target="_blank">james.h.cownie@intel.com</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; <a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a><br>
> Subject: Re: [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries<br>
><br>
> I'd support some of Jame's comments if liboffload wasn't glued to OMP<br>
> as it is now. My attempts to decouple it into something with better<br>
> design layering and outside of OMP source repo, have failed. For it to<br>
> be advocated as "the" offload lib - it needs a home (imnsho) outside<br>
> of OMP. Somewhere that others can easily play with it and not pay the<br>
> OMP tax. It may tick some of the boxes which have been mentioned, but<br>
> I'm curious how well it does when put under real workloads.<br>
><br>
> On Tue, Mar 15, 2016 at 12:53 AM, Cownie, James H via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> Jason,<br>
>><br>
>><br>
>><br>
>> It’s great that Google are interested in contributing to the development of<br>
>> LLVM in this area, and that you have code to support offload.<br>
>><br>
>> However, I’m not sure that all of it is needed, since LLVM already has the<br>
>> offload library which has been being developed in the context of OpenMP, but<br>
>> actually provides a general facility. It has been a part of LLVM since April<br>
>> 2014, and is already being used to offload to both Intel Xeon Phi and (at<br>
>> least NVidia) GPUs. (The IBM folks can tell you more about that!)<br>
>><br>
>><br>
>><br>
>> The main difference I see (at a very first glance!) is that your<br>
>> StreamExecutor interfaces seem to be aimed more at end user code, whereas<br>
>> the interface to the existing offload library has not been designed for the<br>
>> user, but to be an interface from the compiler. That has advantages and<br>
>> disadvantages<br>
>><br>
>> Advantages:<br>
>><br>
>> · It is a C level interface, so is callable from C,C++ and Fortran<br>
>><br>
>> Disadvantages:<br>
>><br>
>> · Using it directly from C++ user code may be harder than using<br>
>> StreamExecutor.<br>
>><br>
>><br>
>><br>
>> However, there is nothing in the interface that prevents it from being used<br>
>> with CUDA or OpenCL, and it already seems to support the low level features<br>
>> you cited as StreamExecutor’s advantages, though not the “looks just like<br>
>> CUDA” aspects, since it’s explicitly vendor neutral.<br>
>><br>
>><br>
>><br>
>>> StreamExecutor:<br>
>><br>
>>><br>
>><br>
>>> * abstracts the underlying accelerator platform (avoids locking you into a<br>
>><br>
>>> single vendor, and lets you write code without thinking about which<br>
>><br>
>>> platform you'll be running on).<br>
>><br>
>> Liboffload does this (and has a specific design for how to abstract new<br>
>> devices and support them using device specific libraries).<br>
>><br>
>>> * provides an open-source alternative to the CUDA runtime library.<br>
>><br>
>> I am not a CUDA expert, so I can’t comment on this! As before, IBM should<br>
>> comment.<br>
>><br>
>>> * gives users a stream management model whose terminology matches that of<br>
>>> the CUDA programming model.<br>
>><br>
>> This is not abstract, but seems CUDA target specific, which is, if anything,<br>
>> worrying for a supposedly vendor-neutral interface!<br>
>><br>
>>> * makes use of modern C++ to create a safe, efficient, easy-to-use<br>
>>> programming interface.<br>
>><br>
>> No, because liboffload is an implementation layer, not intended to be<br>
>> user-visible.<br>
>><br>
>><br>
>><br>
>>> StreamExecutor makes it easy to:<br>
>><br>
>>><br>
>><br>
>>> * move data between host and accelerator (and also between peer<br>
>>> accelerators).<br>
>><br>
>> Liboffload supports this.<br>
>><br>
>>> * execute data-parallel kernels written in the OpenCL or CUDA kernel<br>
>>> languages.<br>
>><br>
>> I believe this should be easy; IBM can comment better, since they have been<br>
>> working on GPU support.<br>
>><br>
>>> * inspect the capabilities of a GPU-like device at runtime.<br>
>><br>
>>> * manage multiple devices.<br>
>><br>
>> Liboffload supports this.<br>
>><br>
>><br>
>><br>
>> We’d therefore be very interested in seeing an approach that implemented a<br>
>> C++ specific user-friendly interface on top of the existing liboffload<br>
>> functionality, but we don’t see a reason to rework the OpenMP implementation<br>
>> to use StreamExecutor (since what LLVM already has is working fine, and<br>
>> supporting offload to both GPUs and Xeon Phi).<br>
>><br>
>><br>
>><br>
>> -- Jim<br>
>><br>
>> James Cownie <<a href="mailto:james.h.cownie@intel.com" target="_blank">james.h.cownie@intel.com</a>><br>
>> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)<br>
>><br>
>> Tel: +44 117 9071438<br>
>><br>
>><br>
>><br>
>> ---------------------------------------------------------------------<br>
>> Intel Corporation (UK) Limited<br>
>> Registered No. 1134945 (England)<br>
>> Registered Office: Pipers Way, Swindon SN3 1RJ<br>
>> VAT No: 860 2173 47<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
> ---------------------------------------------------------------------<br>
> Intel Corporation (UK) Limited<br>
> Registered No. 1134945 (England)<br>
> Registered Office: Pipers Way, Swindon SN3 1RJ<br>
> VAT No: 860 2173 47<br>
><br>
> 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.<br>
_______________________________________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>