public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Verbin <iverbin@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org, Kirill Yukhin <kirill.yukhin@gmail.com>
Subject: Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing
Date: Mon, 24 Aug 2015 19:10:00 -0000	[thread overview]
Message-ID: <20150824185636.GA58465@msticlxl57.ims.intel.com> (raw)
In-Reply-To: <20150824122657.GJ9425@tucnak.redhat.com>

On Mon, Aug 24, 2015 at 14:26:57 +0200, Jakub Jelinek wrote:
> On Mon, Jul 20, 2015 at 09:53:42PM +0300, Ilya Verbin wrote:
> > Latest liboffloadmic (I'm preparing an update for trunk) can take some pointer
> > *ptr* as argument of __offload_offload, which is used for execution and data
> > transfer.  When given job is finished, it will call some callback in libgomp on
> > host, passing *ptr* back to it, thus libgomp can distinguish which job has
> > been finished.  BTW, which word to use here to avoid confusion? (task? job?)
> > 
> > I'm going to prototype something in libgomp using this interface.
> 
> Based on the recent largish thread on omp-lang, it seems that the intent
> is that depend clause on target* constructs is for an implicit "target task"
> on the host side, so sorry for understanding it as dependencies on the
> implicit task on the device instead before.  As the "target task" is
> supposed to be merged (i.e. sharing ICVs and variables), for
> constructs without nowait and depend clauses we can do what we do right now,
> perhaps later with some optimizations trying to invoke other tasks if
> waiting for the hardware.

I just got back from vacation, and trying to understand that conversation :)

> For target* constructs with nowait and/or depend clauses, we'll need to pass
> in the depend info (which is a pointer to array of addresses, with first
> "address" being total count and second "address" being number of out/inout
> dependencies at the beginning, and whether nowait is present or not (a bit
> somewhere), then create some struct gomp_task for it supposedly with a new
> GOMP_TASK_TARGET kind, and handle the dependency waiting etc. like for other
> tasks, except that it will not have a real body, but saved arguments from
> the GOMP_target* call (at least for not immediately 
> satisfied dependency my understanding from the mail thread is that
> the data transfer operations are supposed to start only when the dependency
> is met).

So, what will happen with a target task on the host when all dependencies are
satisfied and it is ready to start?  As I understood:
* libgomp will call GOMP_OFFLOAD_run with a new 'async' argument, or a new
function GOMP_OFFLOAD_run_async, which will start target function on the device
and immediately return control to libgomp.
* The task will go into some pending state, allowing to run another tasks on the
host (I'm not very familiar with task.c yet).
* When target function is finished, the target runtime library will notify
libgomp by callback.  libgomp will remove the task and make dependent tasks (if
any) ready to start.
Is this correct?

  -- Ilya

  reply	other threads:[~2015-08-24 18:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29 11:44 Jakub Jelinek
2015-04-29 11:55 ` Thomas Schwinge
2015-04-29 12:31   ` Jakub Jelinek
2015-04-29 15:20     ` Thomas Schwinge
2015-06-09 18:39     ` Ilya Verbin
2015-06-09 20:25       ` Jakub Jelinek
2015-06-25 19:47         ` Ilya Verbin
2015-06-25 20:31           ` Jakub Jelinek
2015-07-17 16:47             ` Ilya Verbin
2015-07-17 16:54               ` Jakub Jelinek
2015-07-20 16:18                 ` Jakub Jelinek
2015-07-20 18:31                   ` Jakub Jelinek
2015-07-23  0:50                     ` Jakub Jelinek
2015-07-24 20:33                       ` Jakub Jelinek
2015-07-29 17:30                         ` [gomp4.1] Various accelerator updates from OpenMP 4.1 Jakub Jelinek
2015-09-04 18:17                           ` Ilya Verbin
2015-09-04 18:25                             ` Jakub Jelinek
2015-09-07 12:48                             ` Jakub Jelinek
2015-07-20 19:40                 ` [gomp4.1] Initial support for some OpenMP 4.1 construct parsing Ilya Verbin
2015-08-24 12:38                   ` Jakub Jelinek
2015-08-24 19:10                     ` Ilya Verbin [this message]
2015-06-11 12:52       ` [gomp4.1] map clause parsing improvements Jakub Jelinek
2015-10-19 10:34         ` Thomas Schwinge
2015-10-19 10:46           ` Jakub Jelinek
2015-10-19 15:14             ` Thomas Schwinge
2015-10-20 10:10               ` Jakub Jelinek
2015-10-26 13:04                 ` Ilya Verbin
2015-10-26 13:17                   ` Jakub Jelinek
2015-10-26 14:16                     ` Ilya Verbin
2016-03-17 14:34             ` Thomas Schwinge
2016-03-17 14:37               ` Jakub Jelinek
2016-03-17 14:55                 ` Jakub Jelinek
2016-03-17 15:13                 ` Rename GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE (was: [gomp4.1] map clause parsing improvements) Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150824185636.GA58465@msticlxl57.ims.intel.com \
    --to=iverbin@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=kirill.yukhin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).