public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Hongtao Liu <hongtao.liu@intel.com>, Xinmin Tian <xinmin.tian@intel.com>
Cc: <gcc@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>,
	Tobias Burnus <tobias@codesourcery.com>,
	Kirill Yukhin <kirill.yukhin@gmail.com>,
	Richard Biener <richard.guenther@gmail.com>
Subject: RE: GCC/OpenMP offloading for Intel GPUs?
Date: Tue, 21 Sep 2021 12:31:04 +0200	[thread overview]
Message-ID: <87bl4m9q53.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <CY4PR11MB2007237F72E5C752BC24A64FE5DC9@CY4PR11MB2007.namprd11.prod.outlook.com>

Hi!

On 2021-09-16T01:40:40+0000, "Liu, Hongtao" <hongtao.liu@intel.com> wrote:
> Rely from Xinmin and adding him to this thead.

Thanks.  :-)

By the way: if you are registered for the Linux Plumbers Conference 2021,
<https://linuxplumbersconf.org/event/11/>, we may also continue this
discussion in the GCC "BoF: Offloading with OpenMP & OpenACC",
<https://linuxplumbersconf.org/event/11/contributions/1000/>.

> IGC is open sourced. It takes SPIR-V IR and LLVM IR.  We need "GCC IR to SPIR-V translator"

Understood that we need a GCC back end producing SPIR-V, complementing
the existing support for Nvidia GPUs via nvptx back end (producing
textual PTX code), and for AMD GPUs via GCN back end (producing GCN
assembly).

Would you please explain what it means that "IGC [...] takes [...] LLVM
IR"?  Can LLVM IR be used to describe the OpenMP 'target' regions and
properly express GPU multi-level parallelism?  If that is possible in
pure LLVM IR, and given that:

> similar to "LLVM-IR to SPIR-V translator" we have for LLVM-IR.

..., this already exists, does it follow that GCC wouldn't actually need
a SPIR-V back end, but could instead "simply" generate LLVM IR from GCC
IR?

(I remember <https://dragonegg.llvm.org/> "DragonEgg - Using LLVM as a
GCC backend", which at least to me still has a certain appeal on its own
grounds.  I understand not everyone in the GCC community will agree...)

Would such an approach make any sense?

> How does GCC support  device library?

I'm not sure I'm correctly understanding the question.

For both nvptx and GCN offloading compilation, there is a device code
linking step, where offload target libraries may be linked in.  (The
results then get embedded into the host "FAT" binaries.)

Then, there is libgomp ("GNU Offloading and Multi Processing Runtime
Library"), which contains plugins for each offload target, for loading
offload code to the devices, memory management, kernel launches, etc.
For nvptx, this uses the CUDA Driver library, and for GCN it uses
'libhsa-runtime64.so'.  A similar plugin would need to be written for the
corresponding Intel GPU device-access library.


Still remains the question who is going to do the work: are Intel
planning to do that work (themselves, like for Intel MIC offloading back
then), or interested in hiring someone to do it, or not (actively)
interested in helping GCC support Intel GPUs?


Grüße
 Thomas


>>-----Original Message-----
>>From: Thomas Schwinge <thomas@codesourcery.com>
>>Sent: Wednesday, September 15, 2021 7:20 PM
>>To: Liu, Hongtao <hongtao.liu@intel.com>
>>Cc: gcc@gcc.gnu.org; Jakub Jelinek <jakub@redhat.com>; Tobias Burnus
>><tobias@codesourcery.com>; Kirill Yukhin <kirill.yukhin@gmail.com>; Richard
>>Biener <richard.guenther@gmail.com>
>>Subject: RE: GCC/OpenMP offloading for Intel GPUs?
>>
>>Hi!
>>
>>On 2021-09-15T02:00:33+0000, "Liu, Hongtao via Gcc" <gcc@gcc.gnu.org>
>>wrote:
>>> I got some feedback from my colleague
>>
>>Thanks for reaching out to them.
>>
>>> -----------------
>>> What we need from GCC
>>>
>>> 1. generate SPIR-V
>>> 2. offload bundler to create FAT object
>>> --------------
>>>
>>> If the answer is yes for both, they can hook it up with libomptarget library
>>and our IGC back-end.
>>
>>OK, I didn't remember Intel's use of SPIR-V as intermediate representation
>>(but that's certainly good!), and leaving aside the technical/implementation
>>issues (regarding libomptarget etc. use, as brought up by Jakub), the question
>>then is: are Intel planning to do that work (themselves, like for Intel MIC
>>offloading back then), or interested in hiring someone to do it, or not?
>>
>>
>>Grüße
>> Thomas
>>
>>
>>>>-----Original Message-----
>>>>From: Thomas Schwinge <thomas@codesourcery.com>
>>>>Sent: Wednesday, September 15, 2021 12:57 AM
>>>>To: gcc@gcc.gnu.org
>>>>Cc: Jakub Jelinek <jakub@redhat.com>; Tobias Burnus
>>>><tobias@codesourcery.com>; Kirill Yukhin <kirill.yukhin@gmail.com>;
>>>>Liu, Hongtao <hongtao.liu@intel.com>
>>>>Subject: GCC/OpenMP offloading for Intel GPUs?
>>>>
>>>>Hi!
>>>>
>>>>I've had a person ask about GCC/OpenMP offloading for Intel GPUs (the
>>>>new ones, not MIC, obviously), to complement the existing support for
>>>>Nvidia and AMD GPUs.  Is there any statement other than "ought to be
>>>>doable; someone needs to contribute the work"?
>>>>
>>>>
>>>>Grüße
>>>> Thomas
>>>>-----------------
>>>>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
>>-----------------
>>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
-----------------
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:[~2021-09-21 10:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14 16:57 Thomas Schwinge
2021-09-15  2:00 ` Liu, Hongtao
2021-09-15  9:19   ` Richard Biener
2021-09-15  9:25     ` Jakub Jelinek
2021-09-15 11:19   ` Thomas Schwinge
2021-09-16  1:40     ` Liu, Hongtao
2021-09-21 10:31       ` Thomas Schwinge [this message]
2021-09-21 14:10         ` Tian, Xinmin

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=87bl4m9q53.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hongtao.liu@intel.com \
    --cc=jakub@redhat.com \
    --cc=kirill.yukhin@gmail.com \
    --cc=richard.guenther@gmail.com \
    --cc=tobias@codesourcery.com \
    --cc=xinmin.tian@intel.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).