Hi! On 2021-09-16T01:40:40+0000, "Liu, Hongtao" <hongtao....@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 <tho...@codesourcery.com> >>Sent: Wednesday, September 15, 2021 7:20 PM >>To: Liu, Hongtao <hongtao....@intel.com> >>Cc: gcc@gcc.gnu.org; Jakub Jelinek <ja...@redhat.com>; Tobias Burnus >><tob...@codesourcery.com>; Kirill Yukhin <kirill.yuk...@gmail.com>; Richard >>Biener <richard.guent...@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 <tho...@codesourcery.com> >>>>Sent: Wednesday, September 15, 2021 12:57 AM >>>>To: gcc@gcc.gnu.org >>>>Cc: Jakub Jelinek <ja...@redhat.com>; Tobias Burnus >>>><tob...@codesourcery.com>; Kirill Yukhin <kirill.yuk...@gmail.com>; >>>>Liu, Hongtao <hongtao....@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
