[Openmp-dev] Location for omptarget

[Narayanaswamy, Ravi via Openmp-dev]

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.

From: Yonghong Yan [mailto:yanyh15 at gmail.com]
Sent: Friday, September 30, 2016 9:09 AM
To: C Bergström <cbergstrom at pathscale.com>
Cc: Narayanaswamy, Ravi <ravi.narayanaswamy at intel.com>; openmp-dev <openmp-dev at lists.llvm.org>
Subject: Re: [Openmp-dev] Location for omptarget



On Fri, Sep 30, 2016 at 9:39 AM, C Bergström <cbergstrom at pathscale.com<mailto:cbergstrom at pathscale.com>> wrote:
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

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)


On Fri, Sep 30, 2016 at 8:58 PM, Yonghong Yan <yanyh15 at gmail.com<mailto:yanyh15 at gmail.com>> wrote:
>
>
> On Fri, Sep 30, 2016 at 8:39 AM, C Bergström <cbergstrom at pathscale.com<mailto:cbergstrom at pathscale.com>>
> wrote:
>>
>> On Fri, Sep 30, 2016 at 8:30 PM, Yonghong Yan via Openmp-dev
>> <openmp-dev at lists.llvm.org<mailto:openmp-dev at lists.llvm.org>> wrote:
>> >
>> > 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160930/4c9595e9/attachment.html>