Description

Maxzor

opened on Dec 29, 2021

Issue body actions

Hello,
There is a team dedicated to packaging ROCm natively in Debian.
As far as I can tell, our progress is pretty good and the lower third of the stack, up until rocr-runtime and comgr, before hipamd,
is packaged without much issue and soon to be published.
This is all working so far directly with upstream LLVM 13, without the ROCm llvm-project fork.

ROCm build system cmake is still littered with HIP_CLANG_PATH and other flags:
What is still preventing the stack from using the upstream Clang 13 and AMDGPU backend?

Reacted by Joe Schoonover

Activity

1. Maxzor commented on Dec 30, 2021

   

   Maxzor

   on Dec 30, 2021

   Author

   More actions

   Quoting AMD fellow Cordell Bloor in https://lists.debian.org/debian-ai/2021/05/msg00034.html :

   about the progress on upstreaming into LLVM. It seems that the core features required for building ROCm are now all in LLVM trunk. The main features specific to the AMD fork are [...]

   • openmp offloading,
   • __hip_atomic builtin functions,
   • the -parallel-jobs flag,
   • the option to delegate to another compiler for further CPU optimizations.

   [...]

   Most new development is upstreamed quickly.

   I would enjoy getting an ELI5, an overview, on such above functionalities that you develop outside LLVM. I am also keen to know if a realistic, short-term perspective on being able to un-bunde the AMD-flavored LLVM from ROCm packages, exists.
2. Maxzor

   changed the title [-][Debian official packaging] How is ROCm Clang still needed?[/-] [+][Debian official packaging] How is ROCm LLVM fork still needed?[/+] on Dec 30, 2021
3. Maxzor commented on Dec 30, 2021

   

   Maxzor

   on Dec 30, 2021 · Hidden as outdated

   Author

   show commentMore actions
4. Maxzor commented on Dec 30, 2021

   

   Maxzor

   on Dec 30, 2021 · Hidden as outdated

   Author

   show commentMore actions
5. Maxzor commented on Dec 31, 2021

   

   Maxzor

   on Dec 31, 2021 · Hidden as outdated

   Author

   show commentMore actions
6. Maxzor commented on Jan 1, 2022

   

   Maxzor

   on Jan 1, 2022

   Author

   More actions

   Good news!

   The last issue that I had was related to debian:testing llvm-13 packages being not finished in testing.
   I updated the repo used to answer the question of this thread
   https://salsa.debian.org/maxzor/rocm-builder-experimental/-/tree/main/
   ROCm compiles from what I've seen with vanilla llvm-13 on debian!

   The tweaks are detailed in this thread, they sum up from memory to:

   • minor comgr patch
   • minor hipcc patch
   • disable parallel-job clang flags patched by AMD and not yet upstreamed for device code compilation, which takes much longer.

   My benchmark results for rocTHRUST are:
   AMD/Vanilla STL 98.54%
   AMD/VANILLA Thrust 111.38%
   So a rough 10% perf advantage for the AMD fork.

   To be noted, 2 tests out of ~100 do not pass with vanilla LLVM.
   See the directory "results" in the above "rocm-builder-experimental" repo for full details.
7. cgmb commented on Jan 4, 2022

   

   cgmb

   on Jan 4, 2022

   More actions

   @yxsamliu might be able to answer your LLVM questions. Most of my knowledge of the ROCm LLVM fork comes from him.
8. yxsamliu commented on Jan 4, 2022

   

   yxsamliu

   on Jan 4, 2022

   Contributor

   More actions

   openmp offloading,
   @saiislam is working on upstreaming it. Do we have an ETA on it? Thanks.

   __hip_atomic builtin functions,
   upstreamed

   the -parallel-jobs flag,
   I have a Phabricator review https://reviews.llvm.org/D69582 however it is blocked on https://reviews.llvm.org/D52193.

   the option to delegate to another compiler for further CPU optimizations.
   will not be upstreamed since it depends on closed source code for CPU optimizations.
9. saiislam commented on Jan 4, 2022

   

   saiislam

   on Jan 4, 2022

   Member

   More actions

   @ronlieb, please have a look at the query.
10. ronlieb commented on Jan 4, 2022

    

    ronlieb

    on Jan 4, 2022

    More actions

    We do not have an ETA for upstreaming OpenMP offloading to upstream. Rather we are in the process of upstreaming various features as they are developed, as well as older functionality. From my perspective, LLVM 13 was barely functional for AMDGPU OpenMP offloading as it was the first release to attempt to support AMDGPU OpenMP offloading( a good first step). The upcoming LLVM 14 should have increased robustness for AMDGPU OpenMP offloading. However, within AMD we have and continue to use our amd-stg-open branch of LLVM to produce a ROCm compiler product for a variety of reasons including content not yet upstreamed, and extensive qualification testing for our ROCm product.
11. Maxzor commented on Jan 7, 2022

    

    Maxzor

    on Jan 7, 2022 · Hidden as off-topic

    Author

    show commentMore actions
12. ppanchad-amd commented on Apr 3, 2024

    

    ppanchad-amd

    on Apr 3, 2024

    More actions

    @Maxzor Can you please test with latest ROCm 6.0.2 (HIP 6.0.32831)? If resolved, please close ticket. Thanks!
13. cgmb commented on Apr 3, 2024

    

    cgmb

    on Apr 3, 2024

    More actions

    I think this question has been answered. The Debian packaging for ROCm is fairly mature now, and it does not use the ROCm LLVM fork.

    Reacted by Silvio Traversaro
14. cgmb

    closed this as completedon Apr 3, 2024

Issue actions