search for: liboffload

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!), in...

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

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

...orry 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 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, s...

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

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 functionalities. On a high-level...

...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 platform in StreamExecutor, or to provide a new implementation for an existing platform (e.g. using liboffload to implement the CUDA platform). I wrote up this doc in response to a lot of good questions I am getting about the details of how StreamExecutor might work with the code OpenMP already has in place. Best Regards, -Jason On Tue, Mar 15, 2016 at 12:28 PM Andrey Bokhanko <andreybokhanko at gmail...

On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org> wrote: > 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 > functio...

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

...t; 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 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 i...

...9;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 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 platfo...

...t;cbergstrom at pathscale.com> wrote: > > On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> 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 overlapp...

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

Hi Reading through the comments: both Chris and Chandler referenced to liboffload, while I thought the subject of conversation was libomptarget and SE. I am being picky about names because liboffload is a library available as part of omp (llvm's openmp runtime library) that, I believe, only targets Intel Xeon Phi. Did you mean liboffload or libomptarget? Thanks -- Carlo...

...;looks just like CUDA" aspects, since it's explicitly vendor neutral. > StreamExecutor: > > * abstracts the underlying accelerator platform (avoids locking you into a > single vendor, and lets you write code without thinking about which > platform you'll be running on). Liboffload does this (and has a specific design for how to abstract new devices and support them using device specific libraries). > * provides an open-source alternative to the CUDA runtime library. I am not a CUDA expert, so I can't comment on this! As before, IBM should comment. > * gives users a...

...e: [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries On Mon, Mar 14, 2016 at 6:51 PM Jason Henline via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote: 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. I think that having a liboffload plugin would be nice, but I don't think we s...

...g/pipermail/llvm-dev/2016-March/096576.html> Best, -- Mehdi > On Mar 28, 2016, at 10:12 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 functionalities. > On a...

I can't comment on all the things not directly used by llvm community, but I feel pretty strongly that 1) An independent project like liboffload should exist ; which 2) Projects like SE and OpenMP should both be using it ; and further 3) SE shouldn't just do their own thing because they haven't figured out how to make it work with other projects that already have some overlapping behaviour --------- If my points above are invalid -...

...dge when we get there. I'm currently not > specifically interested in these pieces, I've mentioned the specific > and concrete use cases I have in mind. > >>>> > My concrete vision is > SE is a programming model and needs a dedicated home. It can start > under liboffload but gradually needs to be refactored. ‎This is the > same as OMP. > #2 SE, OMP and others long term target liboffload which then handles > the target specific stuff. Be that AVX512/vec onload/offload or > GPU.. > Liboffload will have many backends (nvidia/intel/amd) and many > c...