search for: streamexecutor

...are parallel libraries, especially those closely tied to compiler technology like runtime and math libraries. We would like to develop these in the open, and the natural place seems to be as a subproject in LLVM if others in the community are interested. Initially, we'd like to open source our StreamExecutor runtime library, which is used for simplifying the management of data-parallel workflows on accelerator devices and can also be extended to support other hardware platforms. We'd like to teach Clang to use StreamExecutor when targeting CUDA and work on other integrations, but that makes much mo...

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...

...sks and the accelerator tasks). Based on your comments, I think that supporting host-side tasks sounds like something that should be added to our roadmap, and it should be pretty simple to do within the current model. However, supporting dependency edges between different "platforms" (as StreamExecutor calls them) such as host and GPU could be slightly more challenging. The current model organizes each stream of execution as belonging to a parent platform, and streams are the structures that are meant to manage dependency edges. It will probably take some thought to decide how to do that in the r...

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 StreamExecutor and OpenMP are quite different (and each warrants its place under the sun!), internal SE's offloading int...

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 ( https://github.com/henline/streamexecutordoc/blob/master/se_and...

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 p...

...fe-dev] RFC: Proposing an LLVM subproject for > parallelism runtime and support libraries > > Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org> > ------------------------------ > > > > > Jason, > > I concur with your decision since OMP and StreamExecutor fundamentally > differ in how dependences between consecutive tasks are expressed. OMP uses > task dependences to express constraint ordering between tasks that execute > on the host and/or on a particular device. Obviously, a stream is a DAG but > with very specific constraints (one li...

...ith respect to what they provide to the compiler. Can you elaborate? Thanks, -- Mehdi > On Mar 28, 2016, at 9:37 AM, Jason Henline via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 (https://github.com/henline/streamexecutordoc/blob/master/se_and_...

...t;> for parallelism runtime and support libraries >> >> Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org> >> ------------------------------ >> >> >> >> >> Jason, >> >> I concur with your decision since OMP and StreamExecutor fundamentally >> differ in how dependences between consecutive tasks are expressed. OMP uses >> task dependences to express constraint ordering between tasks that execute >> on the host and/or on a particular device. Obviously, a stream is a DAG but >> with very specific con...

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 d...

...lists.llvm.org Date: 03/28/2016 01:44 PM Subject: Re: [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org> Jason, I concur with your decision since OMP and StreamExecutor fundamentally differ in how dependences between consecutive tasks are expressed. OMP uses task dependences to express constraint ordering between tasks that execute on the host and/or on a particular device. Obviously, a stream is a DAG but with very specific constraints (one linear ordering per st...

...rt libraries >>> >>> Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org> >>> ------------------------------ >>> >>> >>> >>> >>> Jason, >>> >>> I concur with your decision since OMP and StreamExecutor fundamentally >>> differ in how dependences between consecutive tasks are expressed. OMP uses >>> task dependences to express constraint ordering between tasks that execute >>> on the host and/or on a particular device. Obviously, a stream is a DAG but >>> with v...

...n 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, > > I'm trying to better understand your StreamExecutor proposal and how > it relates to other parallel programming models and runtimes such as > RAJA [1], KOKKOS [2], or some hypothetical SPARK C++ API. > > Please correct me if I'm misunderstanding your proposal, but I think > the essence of what you want from the compiler is type s...

...t;> Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org> >>>> ------------------------------ >>>> >>>> >>>> >>>> >>>> Jason, >>>> >>>> I concur with your decision since OMP and StreamExecutor fundamentally >>>> differ in how dependences between consecutive tasks are expressed. OMP uses >>>> task dependences to express constraint ordering between tasks that execute >>>> on the host and/or on a particular device. Obviously, a stream is a DAG but >&gt...

..." <openmp-dev-bounces at lists.llvm.org> >>>>> ------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> Jason, >>>>> >>>>> I concur with your decision since OMP and StreamExecutor fundamentally >>>>> differ in how dependences between consecutive tasks are expressed. OMP uses >>>>> task dependences to express constraint ordering between tasks that execute >>>>> on the host and/or on a particular device. Obviously, a stream is a DAG...

...t of OpenMP, but actually provides a general facility. It has been a part of LLVM since April 2014, and is already being used to offload to both Intel Xeon Phi and (at least NVidia) GPUs. (The IBM folks can tell you more about that!) The main difference I see (at a very first glance!) is that your StreamExecutor interfaces seem to be aimed more at end user code, whereas the interface to the existing offload library has not been designed for the user, but to be an interface from the compiler. That has advantages and disadvantages Advantages: * It is a C level interface, so is callable from C,C++ an...

...> > -- > Mehdi > > >> On Mar 28, 2016, at 9:37 AM, Jason Henline via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> 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 (https://github.com/henline/streamexecutordoc/blob/master/se_and_...

...a general facility. It has been a part of LLVM since April > 2014, and is already being used to offload to both Intel Xeon Phi and (at > least NVidia) GPUs. (The IBM folks can tell you more about that!) > > > > The main difference I see (at a very first glance!) is that your > StreamExecutor interfaces seem to be aimed more at end user code, whereas > the interface to the existing offload library has not been designed for the > user, but to be an interface from the compiler. That has advantages and > disadvantages > > Advantages: > > · It is a C level inter...

...ndler, 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 of those above and providing unified interfaces across all targets to be supported - the performance libraries collection that can be re-used in different programming models and be targeting different host/targets pla...

The parallel-libs LLVM subproject is now set up and ready for code development. This is the subproject that is meant to house the StreamExecutor parallel runtime library, possibly the OpenMP target runtime libraries, and other libraries devoted to handling parallelism in LLVM (see the README currently checked into the parallel-libs base directory for the project charter). The parallel-libs subproject now has a working git mirror and arccon...