From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 413973858402 for ; Tue, 21 Sep 2021 10:31:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 413973858402 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: Q+q7nDHRu8oBd4sZo1grVzNxSsS4LEPJz5LeMzt1cBJ/E1oVBEmHzPiYvJoLTiDfewYgU9+pnK 1kKapBUsuL1vsA4Eo56x7DSSCFo5E2V2/25YFv+sTuHZzlx1TFD1O/Xz5bR9ipS74vtRK/hMRa xFl8h0+BvKd/M/GjFN5bjzXROz56M320Um8O9ymvz87ETCNDnVM9Ms1O2e58xdtpRCyEmb0Qbw 2HWoQAXl6/DFfv0A3bwRNBkMFJM1ngM6IMsxetp+Z6Wr7zSIOrLqweHQuaRcMlf3mPiKEdsPye chRIeU3RQYK8M0FtuDj/28U4 X-IronPort-AV: E=Sophos;i="5.85,310,1624348800"; d="scan'208";a="66283207" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 21 Sep 2021 02:31:19 -0800 IronPort-SDR: 8fEnfdg5Tr6Mzn7oJpg4OG7Iw/kYnNdX/4us0x6L/u2RvB++KWLRA/1Ni5R4ySOvNWc7lSUkuQ TYHG34Tfh786GUvSeL/aLYCD0AHDu98YXRsDNKNpOlVqWOIchySqqDES3ilI8iMTlDm+3BmUUI NQZD4jAjUCj01oXoXcCxGYBfS86QSCvhzb40Qwa6MDb+AJGkMAPUlTNNH1fHlAPtZmZArljuc/ bq28jjkT2hmn/sOIIMmq2vmL+EcrFk92cHN/qP8GPb11tdeTe3nqXW3eqLLCODq/3tkmsZ/GF6 PJw= From: Thomas Schwinge To: Hongtao Liu , Xinmin Tian CC: , Jakub Jelinek , Tobias Burnus , Kirill Yukhin , Richard Biener Subject: RE: GCC/OpenMP offloading for Intel GPUs? In-Reply-To: References: <87v933nlhn.fsf@dem-tschwing-1.ger.mentorg.com> <87czpat7af.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 21 Sep 2021 12:31:04 +0200 Message-ID: <87bl4m9q53.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2021 10:31:23 -0000 Hi! On 2021-09-16T01:40:40+0000, "Liu, Hongtao" wrote: > Rely from Xinmin and adding him to this thead. Thanks. :-) By the way: if you are registered for the Linux Plumbers Conference 2021, , we may also continue this discussion in the GCC "BoF: Offloading with OpenMP & OpenACC", . > 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 "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=C3=BC=C3=9Fe Thomas >>-----Original Message----- >>From: Thomas Schwinge >>Sent: Wednesday, September 15, 2021 7:20 PM >>To: Liu, Hongtao >>Cc: gcc@gcc.gnu.org; Jakub Jelinek ; Tobias Burnus >>; Kirill Yukhin ; Richa= rd >>Biener >>Subject: RE: GCC/OpenMP offloading for Intel GPUs? >> >>Hi! >> >>On 2021-09-15T02:00:33+0000, "Liu, Hongtao via Gcc" >>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 li= brary >>and our IGC back-end. >> >>OK, I didn't remember Intel's use of SPIR-V as intermediate representatio= n >>(but that's certainly good!), and leaving aside the technical/implementat= ion >>issues (regarding libomptarget etc. use, as brought up by Jakub), the que= stion >>then is: are Intel planning to do that work (themselves, like for Intel M= IC >>offloading back then), or interested in hiring someone to do it, or not? >> >> >>Gr=C3=BC=C3=9Fe >> Thomas >> >> >>>>-----Original Message----- >>>>From: Thomas Schwinge >>>>Sent: Wednesday, September 15, 2021 12:57 AM >>>>To: gcc@gcc.gnu.org >>>>Cc: Jakub Jelinek ; Tobias Burnus >>>>; Kirill Yukhin ; >>>>Liu, Hongtao >>>>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=C3=BC=C3=9Fe >>>> Thomas >>>>----------------- >>>>Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe >>>>201, >>>>80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch= =C3=A4ftsf=C3=BChrer: >>>>Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaft: M=C3=BCnchen= ; >>>>Registergericht M=C3=BCnchen, HRB 106955 >>----------------- >>Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 2= 01, >>80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: >>Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaft: M=C3=BCnchen; >>Registergericht M=C3=BCnchen, HRB 106955 ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955