Hi all,
I've been looking into getting started with using OpenMP 4 to try out the offloading. I've seen some nice presentations explaining the concepts and it sounds usable. However, if I look at the openmp.llvm.org website, I see that this part is still "under development".
Is there some list that I can look at that tells me the currently supported features or is this something I will just need to find out through trial and error?
Cheers,
Roel
Hi Roel
I am not sure if someone already answered your question, but here is a description of the status to the best of my knowledge: offloading support for OpenMP includes implementation of target-related pragmas plus an offloading library, currently called libomptarget.
The implementation of the pragmas happens in Clang and most of the constructs are implemented in trunk, notably except map clause, declare target, target update, and some clauses of teams. These remaining things are being worked on at this time, i.e. the patches are being discussed on phabricator.
libomptarget is present as patches to the openmp library. You can find them here:
http://reviews.llvm.org/D14031
http://reviews.llvm.org/D14253
http://reviews.llvm.org/D14254
Finally, there are additional patches to the driver being discussed by the llvm community. These would enable compilation for different kinds of targets (same target region compiled for host and device selected by command line args), bundling of intermediate files, etc…
Unfortunately, at this point in time putting all of these separate things together may not be easy.
Cheers
– Carlo
Roel Jordans via Openmp-dev —04/02/2016 04:23:25 PM—Hi all, I’ve been looking into getting started with using OpenMP 4 to try out
Hi Carlo,
Thanks for your response! Good to see that things are under review.
Cheers,
Roel
Hi all,
I would like to know what is blocking libomptarget to be merge to the trunk? From the discussion about a common offloading with Google StreamExecutor, my understanding was that both should live separately in a first time... Any news from this side ?
For now, I'm still developing offloading to my own target in the github version of libomptarget on but I would like to update it to a more recent version of clang/llvm.
Thanks,
Hervé
From: "Hervé Yviquel via Openmp-dev" <openmp-dev@lists.llvm.org>
To: "Roel Jordans via Openmp-dev" <openmp-dev@lists.llvm.org>
Sent: Wednesday, June 15, 2016 11:34:27 AM
Subject: Re: [Openmp-dev] OpenMP 4 offloading statusHi all,
I would like to know what is blocking libomptarget to be merge to the
trunk? From the discussion about a common offloading with Google
StreamExecutor, my understanding was that both should live
separately in a first time... Any news from this side ?
That's the plan. The news, as such, is that no one has okay'd those patches, and we need more eyes on the code. If you'd like to help this process, please help review the patches.
Thanks again,
Hal
From: Openmp-dev [mailto:openmp-dev-bounces@lists.llvm.org] On Behalf
Of Hal Finkel via Openmp-dev
Sent: Wednesday, June 15, 2016 7:33 PM
To: Hervé Yviquel
Cc: Roel Jordans via Openmp-dev
Subject: Re: [Openmp-dev] OpenMP 4 offloading status> From: "Hervé Yviquel via Openmp-dev" <openmp-dev@lists.llvm.org>
> To: "Roel Jordans via Openmp-dev" <openmp-dev@lists.llvm.org>
> Sent: Wednesday, June 15, 2016 11:34:27 AM
> Subject: Re: [Openmp-dev] OpenMP 4 offloading status
>
> Hi all,
>
> I would like to know what is blocking libomptarget to be merge to the
> trunk? From the discussion about a common offloading with Google
> StreamExecutor, my understanding was that both should live separately
> in a first time... Any news from this side ?That's the plan. The news, as such, is that no one has okay'd those patches,
and we need more eyes on the code. If you'd like to help this process, please
help review the patches.Thanks again,
Hal
I've reviewed the patches back in February but there are still some of my comments outstanding.
I planned to give my ACK once they are discussed, I think they have been around for review long enough now so that everyone could have commented.
Thanks,
Jonas
Hi Jonas,
We are planning to work on a new revision for libomptarget soon. That was delayed because we wanted to add testing that would be enabled by the changes in the driver. Unfortunately, that got delayed too. We are considering create some unit tests that use the libomptarget interface directly so that the progress there can be more independent of what happens in the driver/compiler side.
Thanks for your patience,
Samuel
So it's not lost or forgotten -
If the libomptarget is the same thing I'm thinking it is, then it
certainly hasn't had all my comments and feedback addressed.
1) The design is not friendly to adding more targets
2) If that offloading is meant to be available to another programming
model, it should be abstracted to provide a bit more clean abstraction
instead of just zero layer over the OMP API.
Lastly and it may be just my opinion, but the way that it's actually
coded looks like some 1st year C programmer just got his license to
code. I'd be really surprised if this actually passed the clang/llvm
coding standards..
From: "C Bergström via Openmp-dev" <openmp-dev@lists.llvm.org>
To: "Samuel Antão" <samuelfantao@gmail.com>
Cc: "LLVM-OpenMP (openmp-dev@lists.llvm.org)" <openmp-dev@lists.llvm.org>
Sent: Thursday, June 16, 2016 12:55:01 PM
Subject: Re: [Openmp-dev] OpenMP 4 offloading statusSo it's not lost or forgotten -
If the libomptarget is the same thing I'm thinking it is, then it
certainly hasn't had all my comments and feedback addressed.1) The design is not friendly to adding more targets
2) If that offloading is meant to be available to another programming
model, it should be abstracted to provide a bit more clean
abstraction
instead of just zero layer over the OMP API.Lastly and it may be just my opinion, but the way that it's actually
coded looks like some 1st year C programmer just got his license to
code.
Given that I doubt that's literally true, let's keep the criticism constructive, please. Making comments like this only detracts from your more-constructive points.
-Hal
So for the record all my comments seem pragmatically ignored. #meh
I gave specific comments on that patch for a handful of the nits.
Regardless of my tone - I'd love to see if it passes clang/llvm coding
standards, clang-tidy or lint..
That’s the plan. The news, as such, is that no one has okay’d those patches, and we need more eyes on the code. If you’d like to help this process, please help review the patches.
Ok, I will look again and try to add some comments.
Hi Jonas,
We are planning to work on a new revision for libomptarget soon. That was delayed because we wanted to add testing that would be enabled by the changes in the driver. Unfortunately, that got delayed too. We are considering create some unit tests that use the libomptarget interface directly so that the progress there can be more independent of what happens in the driver/compiler side.
Nice to know, I’m very interested by these unit tests.
Thanks all for your work and answers,
Hervé
Ok, so let's focus on your constructive points.
From: Openmp-dev [mailto:openmp-dev-bounces@lists.llvm.org] On Behalf
Of C Bergström via Openmp-dev
Sent: Thursday, June 16, 2016 8:06 PM
To: Hal Finkel
Cc: LLVM-OpenMP (openmp-dev@lists.llvm.org)
Subject: Re: [Openmp-dev] OpenMP 4 offloading status>> From: "C Bergström via Openmp-dev" <openmp-dev@lists.llvm.org>
>> To: "Samuel Antão" <samuelfantao@gmail.com>
>> Cc: "LLVM-OpenMP (openmp-dev@lists.llvm.org)"
>> <openmp-dev@lists.llvm.org>
>> Sent: Thursday, June 16, 2016 12:55:01 PM
>> Subject: Re: [Openmp-dev] OpenMP 4 offloading status
>>
>> So it's not lost or forgotten -
>>
>> If the libomptarget is the same thing I'm thinking it is, then it
>> certainly hasn't had all my comments and feedback addressed.
>>
>> 1) The design is not friendly to adding more targets
Full disagree: Add a new RTL and implement the methods described in the interface between libomptarget and its RTLs - simple as that.
>> 2) If that offloading is meant to be available to another programming
>> model, it should be abstracted to provide a bit more clean
>> abstraction instead of just zero layer over the OMP API.
Well, it wasn't meant to if I got this correctly. That's why I think the current level of abstraction is just right.
Also, they didn't start coding without a plan but first put together a well-thought design document. That was a joint effort by multiple companies involved in the OpenMP standard and its implementation.
Coming back to your wish of abstraction: The interface of the RTLs for example consists of the following methods: __tgt_rtl_data_alloc and __tgt_rtl_data_retrieve
Please tell me
1) how this is "just zero layer over the OMP API" and
2) what your concrete and detailed proposal would be.
I have read your mails about "3 layer abstraction" but they have all been focusing on a very high-level view without a concrete design that someone could evaluate or even think of.
>>
>> Lastly and it may be just my opinion, but the way that it's actually
>> coded looks like some 1st year C programmer just got his license to
>> code.
>
> Given that I doubt that's literally true, let's keep the criticism constructive,
please. Making comments like this only detracts from your more-
constructive points.
Completely agree with Hal here: Getting personal is surely not the right way to discuss on technical matters.
(I've already worked on the code and looked into implementing OMPT which worked quite good. Which means that the design can't be complete non-sense...)
So for the record all my comments seem pragmatically ignored. #meh
All right, I've commented on the technical topics above.
I gave specific comments on that patch for a handful of the nits.
Regardless of my tone - I'd love to see if it passes clang/llvm coding
standards, clang-tidy or lint..
Ehm no, that's just not how it works in open-source communities: Be respectful to the others involved in a discussion.
(just another random note: you didn't even say sorry and don't seem to change your behavior...)
As for what you'd love to see: Just look into it - that's the power of open source 
Cheers,
Jonas
#1 I think everyone around here is a bit too sensitive
#2 I'll do my best to either:
a. Contribute some headers which directly show the API's I'm talking about
or
b. Some docs which give enough examples and detail that what I'm
talking is tangible.
At that point we can compare 1:1 with how things are in the code
review and maybe have actionable items.
Hi Chris,