Hello, Given that we no longer have ROCm binaries for arm64 and ppc64el arches (LP: #2164631), such steps must be taken. Here is a quick analysis regarding reverse deps of ucc (src: openmpi (arm64 and ppc64el) and src: mpich (arm64)).
1. openmpi Confirmed this is safe. Current `libucc1:arm64` package: ``` Depends: libamdhip64-7 (>= 7.1.0), libc6 (>= 2.38), libibverbs1 (>= 1.1.6), libucx0 ``` `libamdhip64-7` is a runtime dependency of `libucc1` itself, pulled in automatically by `dpkg-shlibdeps` because ucc's own HIP TL links against it internally. It's not something openmpi ever links against or includes headers for. openmpi's code has zero HIP/ROCm calls that go through ucc, it only calls ucc's public API (`ucc_init`, `ucc_collective_*`, etc. via `ucc/api/ucc.h`). Practically: - Build-time: openmpi Build-Depends on `libucc-dev`, which only needs `libucc1` + ucc's public headers. No HIP dev packages (`hipcc`, `libhsa-runtime-dev`, `libhsakmt-dev`) are pulled into openmpi's build chroot, so nothing changes for the build. Current exert from build log: ``` configure: Searching for rocm in default search paths checking for rocm cppflags... checking for rocm ldflags... checking for rocm libs... -lamdhip64 checking for rocm static libs... -lamdhip64 checking for hip/hip_runtime.h... no ``` - Link-time: openmpi binaries get a `DT_NEEDED` on `libucc.so.1` only, not on `libamdhip64.so` (that's an indirect/transitive dependency resolved by the dynamic linker when `libucc1` loads, and satisfied by whatever `libucc1`'s own `Depends:` requires at install time on arches where it still applies). - After the change: the new `libucc1` on arm64/ppc64el simply drops `libamdhip64-7` from its own `Depends:` (one less runtime dep) because it no longer has a HIP TL built in. That has zero effect on openmpi packages/binaries built there. The only real consequence is: on arm64/ppc64el, ucc loses GPU-direct collective acceleration specifically for AMD ROCm memory buffers similarly as on riscv64 where we've never had ROCm binaries published. openmpi doesn't build or ship any ROCm-aware paths of its own on those arches either (no `rocm-dev` build-dep anywhere), so there's no capability we currently expose that regresses. 2. mpich Did the same analysis for mpich, same conclusion maybe even more clearly a non-issue here. Same pattern with `libucc-dev`: - `debian/control`: `libucc-dev [amd64 arm64 ppc64el riscv64]` - same arch list as openmpi. - `debian/rules`: passes `-with-ucc=/usr` on those arches. - `src/mpid/common/ucc/subconfigure.m4` - the UCC check (`PAC_CHECK_HEADER_LIB_EXPLICIT(ucc, [ucc/api/ucc.h], [ucc], [ucc_init_version])`) only probes for the generic ucc header/symbol, identical in nature to openmpi's check. No HIP-specific probing here. One extra thing mpich does that openmpi doesn't: it has a CUDA-awareness check for UCC (runs `ucc_info -b` and greps for `HAVE_CUDA`), but there is no equivalent HIP-awareness check for UCC anywhere in this file — only CUDA is checked. So mpich's build doesn't care whether UCC has a HIP TL built in or not, in either code path. Additionally, mpich's own HIP support is already dead code on all arches: - `debian/rules` derives `HIP_ARCH` by grepping `debian/control` for a `libamdhip64-dev [...]` Build-Depends entry, but `libamdhip64-dev` is not present anywhere in `debian/control`'s Build-Depends. So `HIP_ARCH` is empty and `--with-hip=/usr` is never actually passed to configure on any arch today. - That said, `GPU_SUPPORT="HIP"` isn't gated on the `--with-hip` flag being passed in the first place, it comes from an autodetection macro in `src/mpl/configure.ac`: `PAC_CHECK_HEADER_LIB_OPTIONAL([hip],[hip/hip_runtime_api.h],[amdhip64],[hipStreamSynchronize],...)`, which probes default system paths unconditionally unless `with_hip` is explicitly `"no"`. - The real reason it's inert: no package shipping `hip/hip_runtime_api.h` (a `hip-dev`/`rocm-dev`- type header package) is anywhere in mpich's Build-Depends, directly or transitively, `libucc-dev` only pulls in `libucc1`, not HIP dev headers. So the header is never found, `pac_have_hip` stays `no`, and `GPU_SUPPORT` never becomes `HIP`, regardless of whether the (currently broken) `--with-hip=/usr` plumbing in `debian/rules` fires or not. - Net result: mpich's own RCCL/HIP collective support (`configure.ac:3984`, gated on `GPU_SUPPORT = "HIP"`) is currently unreachable on any architecture, not just arm64/ppc64el, it's already inert today. Conclusion: identical bottom line to openmpi. The removal of ucc's HIP backend on arm64/ppc64el is a non-issue for mpich's build or capabilities, and is even more clearly moot here since mpich never checks for or uses UCC's HIP backend at all, and doesn't currently build its own HIP support on any arch either. Talha, please correct me if I'm wrong, but this can be observed only from looking at current build logs without going deeper. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166379 Title: [rocm] ucc: disable ROCm/HIP backend on arm64, ppc64el (Ubuntu only) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ucc/+bug/2166379/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
