offloading library

Hi all,

I’m interested on the new offloading extension of OpenMP. I looked around and I suppose that you will integrate the libomptarget into the openmp runtime at some point. Is there already a predefined timeline about this ?
I’m going to add another RTL target for my research project but I need to make the library compilable on my laptop (osx).
Can I contribute with a new building system based on CMake ?

Regards,

Hi Herve,

We are planing on doing that integration but we haven’t established a timeline yet. I am currently working on the offloading codegen part, and this library has to be available in order for that to be meaningful. I believe the natural place for it to live would be the OpenMP project. I was planing to work on the porting of what we have in github so it becomes part of LLVM too, but I didn’t have the time yet, so it would be great if you contribute to this and I’m of course available to help.

A question for the maintainers: What would be the good place for that code to be? Any particular subfolder of the current tree?

Many thanks!
Samuel

Hi Samuel,

Cheers,

Tim

We already have the offload library in the OpenMP LLVM repository at http://llvm.org/svn/llvm-project/openmp/trunk/offload/ (or equivalent SVN location). Adding target libraries either in there, or at …/openmp/trunk/libomptarget/foo (where foo is the name of the target) makes sense to me.

Yes, as far as I know liboffload will be used as backend of the libomptarget for Intel® Xeon Phi™. So I guess moving “offload” to a subdirectory of libomptarget makes sense (as you proposed secondly). In the end I don’t really care about the directory structure as long as both are part of the OpenMP project ;-).

Tim

liboffload is not only useful for OMP alone. There's c++AMP, OpenCL
(potentially) and other programming models which are doing
"offloading". Gluing it to OMP reduces the visibility just as much the
reason as why you haven't heard about other offloading runtimes. (They
exist already)

Not to mention the build infrastructure reasons. Look at the whole
libunwind mess and how that eventually needed to get moved to an
independent repo.

I wish people (esp researchers) would look into the current state of
things a bit more before just proposing the thing which seems obvious,
but probably not the best long term plan.

New repo, new project - has 3 layers: top layer API is exposed and
meant for programming models to build on top of, middle is the
transition to the bottom and exposes hardware hooks and bottom layer
is hardware speicifc. I have this model today and it supports (PHI,
AMD dGPU/APU and NVIDIA) across multiple programming models -
including OMP4, OpenACC, C++AMP.. etc

Chirs,

Could you please comment my proposal of offload project organization at http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-June/000731.html

Also having that big experience in different programming models, could you please review the RTL (low level) interface described in http://goo.gl/L1rnKJ - whether it is sufficient to implement support for all model you aware of?

btw - I disagree that this should live *inside* the OpenMP repo. I
think liboffload should be standalone and *outside*. This would make
it visable and useful to multiple projects. The infrastructure and
interface necessary for offloading at the end of the day have a lot of
overlap.