search for: openmp4

...raries seems to have the same goals with > respect to what they provide to the compiler. > > Can you elaborate? (Ignore this please) To butt in with a peanut gallery comment - I suspect it's because liboffload is really just providing a bare set of non-portable API mostly tailored to OpenMP4. Having it support any other programming model is probably going to take real work on the part of refactoring "liboffload". (*cough* *cough* good design) In the end I pessimistically suspect each programming model wanting inclusion will reinvent the wheel and make the same argument each...

...t;> respect to what they provide to the compiler. >> >> Can you elaborate? > > (Ignore this please) > > To butt in with a peanut gallery comment - I suspect it's because > liboffload is really just providing a bare set of non-portable API > mostly tailored to OpenMP4. That can be a valid argument. If indeed liboffload is limited by its original design and a new design can be useful to a wider range of model/target, then the path forward should rather be to replace liboffload. IMO, duplicating libraries/API that the compiler has to be aware of should be really...

...it will become clear. I love your optimistic attitude, but the reality is that successful programming models take a significant amount of work. I'm well aware that they can handle at least part of that, but so far I'm not sure who else will invest in it.. The industry has : CUDA, OpenCL, OpenMP4, OpenACC, C++AMP, Parallel STL(??), some research projects from DOE and dead stuff like HMPP... Are all these so broken that they can't be fixed to fill the same necessity as SE? How similar is it to the failed AMD Stream Computing (sorry AMD) http://www.ele.uri.edu/courses/ele408/StreamGPU.pd...

...ic attitude, but the reality is that successful >> programming models take a significant amount of work. I'm well aware >> that they can handle at least part of that, but so far I'm not sure >> who else will invest in it.. >> >> The industry has : CUDA, OpenCL, OpenMP4, OpenACC, C++AMP, Parallel >> STL(??), some research projects from DOE and dead stuff like HMPP... >> Are all these so broken that they can't be fixed to fill the same >> necessity as SE? > > You're right. SE is certainly different from all of these, higher-level tha...

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 Wed, Jun 1, 2016 at 7:22 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ________________________________ > > From: "C Bergström" <cbergstrom at pathscale.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" > <cfe-dev at lists.llvm.org>,

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 (