[Openmp-dev] Location for omptarget

[Yonghong Yan via Openmp-dev]

On Fri, Sep 30, 2016 at 9:39 AM, C Bergström <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> wrote:
> >
> >
> > On Fri, Sep 30, 2016 at 8:39 AM, C Bergström <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> 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/158be46f/attachment.html>