public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tobias@codesourcery.com>
To: Thomas Schwinge <thomas@codesourcery.com>,
	Martin Jambor <mjambor@suse.cz>,
	Richard Biener <rguenther@suse.de>,
	Jakub Jelinek <jakub@redhat.com>
Cc: Hongtao Liu <hongtao.liu@intel.com>, Michael Matz <matz@suse.de>,
	<gcc-patches@gcc.gnu.org>
Subject: Re: GSoC project idea: Separate Host Process Offloading
Date: Wed, 8 Feb 2023 08:47:46 +0100	[thread overview]
Message-ID: <22bdce2a-4cf5-d2da-b85b-ed16cce49d70@codesourcery.com> (raw)
In-Reply-To: <87ilgdcb0n.fsf@euler.schwinge.homeip.net>

Hi Thomas, hi all,

On 08.02.23 00:26, Thomas Schwinge wrote:
> On 2023-02-02T22:13:20+0100, I wrote:
>> I'd offer to co-mentor, but I'd rather not be the only one.
> Still looking for someone to join, please!  :-)
As kind of mentioned before, I am willing to co-mentor :-)
> Here it is:
> https://gcc.gnu.org/wiki/SummerOfCode#Separate_Host_Process_Offloading
> Please have a look, and fix up if necessary.

Thanks. (Disclaimer: I still have to read it.)

I think this could be also the basis for remote OpenMP offload handling
via the to-be-created target-specific plugin. In this case, to do
offloading to the remote CPU. Writing such an RPC wrapper would be an
independent task, which then should also handle the offloading to a
remote GPU.  — Citing an LLVM paper about such a feature:

"The basic idea behind the Remote OpenMP Offloading implementation is to
provide a transparent communication channel between the
target-independent library on the host with the target-dependent library
on the remote system. This use case matches the well-known remote
procedure calls (RPC) idiom. To facilitate communication, we added two
new components into LLVM/OpenMP that build a tunnel from the host to the
remote system through which all plugin API calls ( in Fig. 3) are
forwarded. The first is a remote offloading plugin () which presents
itself to the host as any other plugin would, i.e., it looks no
different than the NVIDIA GPU offloading plugin. The second is a server
application that must be running on the remote system () that mimics
when it communicates with the remote device plugin, such as the one for
NVIDIA GPU offloading. The bottom row of Fig. 3 illustrates their
interaction with the existing infrastructure."

(From https://link.springer.com/chapter/10.1007/978-3-031-07312-0_16
(requires subscription))

About this topic, see also
https://www.hpcwire.com/off-the-wire/remote-openmp-offloading-paper-recognized-at-isc/
and https://baodishan.com/assets/pdf/iwomp22.pdf (both freely
accessible, the latter has a lot of details).

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

  reply	other threads:[~2023-02-08  7:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-08  8:45 [PATCH] Remove dead code Martin Liška
2021-11-08  8:59 ` Jakub Jelinek
2021-11-08 14:19   ` Jeff Law
2021-11-12 14:27     ` Martin Liška
2021-11-12 14:41       ` H.J. Lu
2021-11-12 14:44         ` Martin Liška
2021-11-12 15:00           ` H.J. Lu
2021-11-12 19:14         ` Richard Biener
2021-11-12 19:18           ` H.J. Lu
2021-11-12 19:52             ` Richard Biener
2022-10-20 11:15         ` Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.) Thomas Schwinge
2022-10-20 11:34           ` Jakub Jelinek
2022-11-04 10:05             ` GCC 13: OpenMP offloading to Intel MIC has been removed (was: Remove support for Intel MIC offloading) Thomas Schwinge
2022-11-04 10:36               ` Jakub Jelinek
2022-10-20 12:33           ` Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.) Michael Matz
2022-10-20 12:40             ` Jakub Jelinek
2022-10-20 13:09               ` Richard Biener
2023-02-01 15:12                 ` Martin Jambor
2023-02-02 21:13                   ` GSoC project idea: Separate Host Process Offloading (was: Remove support for Intel MIC offloading) Thomas Schwinge
2023-02-07 23:26                     ` GSoC project idea: Separate Host Process Offloading Thomas Schwinge
2023-02-08  7:47                       ` Tobias Burnus [this message]
2022-10-20 20:56           ` Remove support for Intel MIC offloading Thomas Schwinge
2022-11-04  9:54             ` Thomas Schwinge
2022-11-04 10:30               ` Jakub Jelinek
2022-11-04 10:35                 ` 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=22bdce2a-4cf5-d2da-b85b-ed16cce49d70@codesourcery.com \
    --to=tobias@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongtao.liu@intel.com \
    --cc=jakub@redhat.com \
    --cc=matz@suse.de \
    --cc=mjambor@suse.cz \
    --cc=rguenther@suse.de \
    --cc=thomas@codesourcery.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).