public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Ilya Verbin <iverbin@gmail.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: Thu, 25 Jun 2015 20:31:00 -0000	[thread overview]
Message-ID: <20150625201058.GK10247@tucnak.redhat.com> (raw)
In-Reply-To: <20150625194529.GB33078@msticlxl57.ims.intel.com>

On Thu, Jun 25, 2015 at 10:45:29PM +0300, Ilya Verbin wrote:
> So, as I understood, three tasks will be generated almost simultaneously in
> foo1: one on host and two on target.
> Target task 1 will be executed immediately.
> Host task will wait for task 1 to be completed on target.
> (Or it is not possible to mix "omp target" and "omp task" dependencies?)
> And task 2 will wait on target for task 1.

My understanding is that you don't create any extra tasks,
but rather you pointer translate the host address from the start of the
variable (or array section; thus the depend clause argument) into
target address, and check if it can be offloaded right away (no need
to wait for dependencies).  If yes, you just offload it, with nowait
without waiting in the caller till it finishes.  If not, you arrange
that when some other offloaded job finishes that provides the dependency,
your scheduled job is executed.
So, the task on the target is the implicit one, what executes the
body of the target region.
In tasking (task.c) dependencies are only honored for sibling tasks,
whether the different target implicit tasks are sibling is questionable and
supposedly should be clarified, but I can't imagine they aren't meant to.
So, you don't really need to care about the task.c dependencies, target.c
could have its own ones if it is easier to write it that way.
Supposedly for nowait you want to spawn or queue the job and return right
away, and for queued job stick it into some data structure (supposedly
inside of libgomp on the host) that when the library is (asynchronously)
notified that some offloaded job finished you check the data structures
and spawn something different.  Or have the data structures on the offloaded
device instead?

In any case, I'd look what the Mentor folks are doing for OpenACC async
offloading, what libmicoffload allows you to do and figure out something
from that.

It is not entirely clear to me if the host tasks and threads that execute the
async #pragma omp target {,enter data,exit data,update} depend(...) {,nowait}
constructs are relevant to it at all, but I bet one task/thread could
supposedly invoke something and a different one invoke something that
depends on it, or waits for its completion (exit data?).

And, wonder how is this really meant to work with host fallback.  Bet that
really needs to be clarified on omp-lang.

	Jakub

  reply	other threads:[~2015-06-25 20:11 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 [this message]
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
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=20150625201058.GK10247@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iverbin@gmail.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).