Location for omptarget

Hi,

I would like to re-start the discussion on the location for omptarget. The code for omptarget is under review. We would like to make progress getting this code into llvm.

Currently we (IBM, Intel, AMD, ANL) have agreed that the right approach is to make omptarget as a subproject of openmp. The reason behind this is that omptarget is dependent on openmp tasking to handle the scheduling of target task which have depend/nowait clause. In the future we could move parts of omptarget to different subproject ie parallel-libs if we have clients wanting to offload and would like to reuse code existing in omptarget. We like to hear from developers about the direction we want to take.

Thanks

Ravi Narayanaswamy.

Hi,

I’m fine with putting libomptarget next to libomp as they are both clearly related to each other and to OpenMP.

However, I wonder whether it might be a good idea to move both under the umbrella of parallel-libs in the long term.

We can still keep the subdomain or make it a redirect, but if LLVM has a collection of “parallel-libs” I think the OpenMP runtime libraries should join the fun.

Just my opinion,

Jonas

Hi,

I’m fine with putting libomptarget next to libomp as they are both clearly
related to each other and to OpenMP.

However, I wonder whether it might be a good idea to move both under the
umbrella of parallel-libs in the long term.

We can still keep the subdomain or make it a redirect, but if LLVM has a
collection of “parallel-libs” I think the OpenMP runtime libraries should
join the fun.

Non-binding votes

I'm +1 for libomptarget to be named liboffload and made a generic new
project. I could potentially help contribute to this. Even if it
starts only with a dependency on tasking, the future direction is
clear.

I'm -1 for libomptarget to be named something confusing or which isn't generic

I'm -1 for inclusion with "parallel-libs". I'm not sure what the
current leadership in that project intends to do. Moving here later is
much easier than trying to extract it out and pick-up broken pieces.

+0 libomptarget to be bundled inside OMP and stay OMP specific. Yay
for code duplication...

From: C Bergström [mailto:cbergstrom@pathscale.com]
Sent: Friday, September 30, 2016 8:18 AM
To: Hahnfeld, Jonas
Cc: Narayanaswamy, Ravi; LLVM-OpenMP (openmp-dev@lists.llvm.org)
Subject: Re: [Openmp-dev] Location for omptarget

> Hi,
>
>
>
> I’m fine with putting libomptarget next to libomp as they are both
> clearly related to each other and to OpenMP.
>
>
>
> However, I wonder whether it might be a good idea to move both under
> the umbrella of parallel-libs in the long term.
>
> We can still keep the subdomain or make it a redirect, but if LLVM has
> a collection of “parallel-libs” I think the OpenMP runtime libraries
> should join the fun.

Non-binding votes

I'm +1 for libomptarget to be named liboffload and made a generic new
project. I could potentially help contribute to this. Even if it starts only with a
dependency on tasking, the future direction is clear.

I'm -1 for libomptarget to be named something confusing or which isn't
generic

We already have "liboffload", I don't think that’s a clever name... I'm fine with "libomptarget" but I don't really care too much about the name.

Some semi-sarcastic questions if you don't mind

I think that's a misunderstanding: I'm only saying that there already is Intel's liboffload that does exactly this but that will not be compatible with Clang. See http://llvm.org/svn/llvm-project/openmp/trunk/offload/

Is libomptarget compatible with clang or is it compatible with clang-omp? Last time I checked it, my findings were that clang wasn't ready for it and I had to use clang-omp instead. Note that I've found libomptarget quite interesting and easily extensible and I hope it will soon get it's way to LLVM projects family (no matter if it's in or out of OpenMP runtime library, along with or as a replacement to liboffload).

Why not just be part of openmp library, no libomptarget thing at all? The
more you develop in the future and the more you will find that it is hard
to separate. That is my vote too.

Yonghong

Yonghong - please subscribe if you're going to post

>
> Why not just be part of openmp library, no libomptarget thing at all? The
> more you develop in the future and the more you will find that it is
hard to
> separate. That is my vote too.

Yonghong - please subscribe if you're going to post

posted using wrong email. I subscribed already.

----------
The big picture idea is that if liboffload or libtarget handles
offloading in a general way it can be leveraged by multiple
programming models. There's nothing OMP specific about copying a
region(kernel), uploading it to a GPU and launching it. Right now
there's like 2-3 different projects all reinventing code which has a
lot of overlap. By sharing it hopefully flushes out a good API as well
as better robustness from increased testing. (That's my idea/goal
anyway... what others have in mind is..)

completely understand. For me, I only care openmp ;-). I honestly would
like to make the whole openmp runtime, including libomptarget, be shared by
other programming models. The intention of parallel-libs is good. I however
do not know how the approach will work in reality if we do not have
something working. people would be tired of waiting and discussing of
runtime interface as well as the functionality, so they will create their
own no matter what. at least this is what I did since creating a wrapper
layer on top of multiple device driver API is not hard.

thus my bet to contribute the whole things to the community is first to
have something working functionality-wise, e.g. support different kinds of
devices, as well as with the current openmp runtime, then we make the API
generalized for others to use.

Yonghong

Maybe I'm reading this wrong and again I'm trying to be sarcastic
(please ignore) - so you think it's best to just blindly rush some
code out and not have proper design or engineering with good API or
reuse in mind? You think 1 programming model should be the only thing
people need and that anyone else using some else doesn't matter..
That's what you're implying, right?

I've been down the hacker path with 5 programming models personally.
Code reuse ends up being extremely helpful and I wish I had someone
pushing me to do proper design 1st. This becomes especially true if
you want to support multiple different archs and device types. I don't
know if I would call them wrapper API, but common interfaces are
possible and imho essential at multiple layers. (With the view that
programming models are broken into pieces of high level and low level
implementation details)

Maybe I'm reading this wrong and again I'm trying to be sarcastic
(please ignore) - so you think it's best to just blindly rush some
code out and not have proper design or engineering with good API or
reuse in mind? You think 1 programming model should be the only thing
people need and that anyone else using some else doesn't matter..
That's what you're implying, right?

You are reading this wrong. Having multiple models is great, especially

for users. however, unifying support of runtime is difficult because of the
difference of the requirement of different models and interfaces.

Yonghong

So are target regions offloaded? What does liboffload do if it doesn't help a target region get offloaded onto the device? (I realize that you can implement a target region as tasks, but why can't we leverage the existing task code to accomplish that then..

The existing task code is used to schedule the target regions, not the data communication which is done in omptarget.

I don’t think we should integrate offloading into openmp. 1) the Expertise for these 2 libraries are different and developers don’t need to understand both to contribute to just one of them. 2) Enables code reuse of offloading for other programming models.