similar to: RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

Hi Hal, Thanks for taking a look at the proposal. The current version of StreamExecutor has partial support for a "host" platform which performs work on the CPU. It's interface is the same as the that of the CUDA platform discussed in the design documentation, but right now it does not support launching user-defined kernels, so it is very limited. The host platform does manage a

Thanks for your input, Hal. I think that having support for running host-side tasks makes this library much more useful, not only for acceleratorless systems, but even for those with accelerators (especially if you can place dependency edges between the host tasks and the accelerator tasks). Based on your comments, I think that supporting host-side tasks sounds like something that should be

----- Original Message ----- > From: "Arpith C Jacob" <acjacob at us.ibm.com> > To: llvm-dev at lists.llvm.org > Cc: jhen at google.com, "Hal J. Finkel" <hfinkel at anl.gov> > Sent: Thursday, March 10, 2016 10:38:46 AM > Subject: Re: [llvm-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries > > Hi Jason, >

Hi Jason, The long discussion made me wondering where this was going, but re-reading you original email [0], there was an acknowledgment of a potential future merge between the projects, and I can of make sense of the current picture. So you can forget about my question below! [0]: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html

Hi Jason, This is probably because I'm not aware of the details, but it was claimed in this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding a new library that the compiler has to be aware of has to bring significant benefit. So it is not clear to me yet why the compiler should target two different runtime libraries that seems to have large chunk of overlapping

> On Apr 22, 2016, at 3:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I feel like this thread got a bit stalled. I'd like to pick it up and try to suggest a path forward. > > I don't hear any real objections to the overall idea of having an LLVM subproject for parallelism runtimes and support libraries. I think we should get that created. I think it

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

Chandler, It seems that the general consensus is to save further discussions for later and go ahead with your proposal. I can add my +1 to this as well. Could you / Jason prepare a proposal on the new project, with all the usual questions covered? One interesting thing is where to put SE and libomptarget in the project's tree. I would be happy to review it from Intel / OpenMP side. Also, as

Chandler, Thank you for getting it up to ML top. I believe we have to move broader than that you just mentioned. The natural separation of the infrastructure into different parts can be across the following lines: - the parallel model of programming - these can be OpenMP, OpenACC, CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc. - the offloading machinery to be used by any

Ahh, I just noticed that Chandler's proposal is to put SE only into this new project, and to keep libomptarget separately, in OpenMP project. I wonder why so? Why SE (a library serving only one PPM so far) is different from libomptarget (a library also serving only one PPM so far)? Are people have opinion on this? Yours, Andrey ===== Software Engineer Intel Compiler Team On Tue, Apr 26,

I created a GitHub repo that contains the documentation I have been creating for StreamExecutor. https://github.com/henline/streamexecutordoc It contains the design docs from the original email in this thread, and it contains a new doc I just made that gives a more detailed sketch of the StreamExecutor platform plugin interface. This shows which methods must be implemented to support a new

Hi Carlo, Thanks for helping to clarify this point about libomptarget vs liboffload, I have been getting confused about it myself. I think the open question concerns libomptarget not liboffload (others can correct me if I have misunderstood). My analysis from looking through the code was that libomptarget had some similarities with the platform support in SE, so I just wanted to consider how

I did a more thorough read through liboffload and wrote up a more detailed doc describing how StreamExecutor platforms relate to libomptarget RTL interfaces. The doc also describes why the lack of support for streams in libomptarget makes it impossible to implement some of the most important StreamExecutor platforms in terms of libomptarget (

Alexandre, Thanks for further shedding some light on the way OpenMP handles dependencies between tasks. I'm sorry for leaving that out of my document, it was just because I didn't know much about the way OpenMP handled its workflows. On Mon, Mar 28, 2016 at 11:43 AM Jason Henline <jhen at google.com> wrote: > Hi Carlo, > > Thanks for helping to clarify this point about

Jason, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? Regarding

Hi Sergos, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? If I

Jason, > If I understand your interpretation of streams, it does not match my > understanding. SE follows the CUDA meaning of "stream". I think of a stream > as a "work queue" and each device can have several active streams. Memory > space on the device does not belong to any stream, so any stream can access > it. The thing that does belong to the stream is the

Jason, It's great that Google are interested in contributing to the development of LLVM in this area, and that you have code to support offload. However, I'm not sure that all of it is needed, since LLVM already has the offload library which has been being developed in the context of OpenMP, but actually provides a general facility. It has been a part of LLVM since April 2014, and is

> I'd support some of Jame's comments if liboffload wasn't glued to OMP as it is now. I certainly have no objection to moving liboffload elsewhere if that makes it more useful to people. There is no real "glue" holding it there; it simply ended up in the OpenMP directory structure because that was an easy place to put it, not because that's the optimal place for it.

Hola Chandler, On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev < openmp-dev at lists.llvm.org> wrote: > It seems like if the OpenMP folks want to add a liboffload plugin to > StreamExecutor, that would be an awesome additional platform, but I don't > see why we need to force the coupling here. > > Let me give you a reason: while user-facing sides of