Source: hypre Followup-For: Bug #882667 Control: retitle -1 hypre: activate GPU support Control: forwarded -1 https://github.com/hypre-space/hypre/issues/1624
The problem with support for alternative GPUs raised in the previous message can be worked around by configuring the build for just one GPU architecture, e.g. -DCMAKE_HIP_ARCHITECTURES=gfx1201 alone. libHYPRE.so then builds successfully, and test programs (e.g. ij) build. But running tests then fails, if the GPU in question is not actually present, which would be the case for instance on debian build daemons. $ ./ij HIP ERROR (code = 100, no ROCm-capable device is detected) at /build/hypre/src/utilities/general.c:307 [cirdan:452875] *** Process received signal *** [cirdan:452875] Signal: Floating point exception (8) [cirdan:452875] Signal code: Integer divide-by-zero (1) [cirdan:452875] Failing at address: 0x7f6144a7aca8 [cirdan:452875] [ 0] /usr/lib/x86_64-linux-gnu/libc.so.6(+0x406b0) [0x7f60206926b0] [cirdan:452875] [ 1] /build/hypre/obj-x86_64-linux-gnu/lib/libHYPRE.so.302(hypre_bind_device_id+0x68) [0x7f6144a7aca8] [cirdan:452875] [ 2] ./ij(+0xf388) [0x55a247f5d388] [cirdan:452875] [ 3] /usr/lib/x86_64-linux-gnu/libc.so.6(+0x29fba) [0x7f602067bfba] [cirdan:452875] [ 4] /usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x87) [0x7f602067c0d7] [cirdan:452875] [ 5] ./ij(+0xe541) [0x55a247f5c541] [cirdan:452875] *** End of error message *** Floating point exception ./ij When inspecting available devices, hipGetDeviceCount returns hipErrorNoDevice if it doesn't find a device. https://rocmdocs.amd.com/projects/HIP/en/latest/reference/hip_runtime_api/modules/device_management.html#_CPPv417hipGetDeviceCountPi And hypre treats any response other than hipSuccess as a fatal error. So it does not fall back to a non-HIP execution path. The issue is raised at https://github.com/hypre-space/hypre/issues/1624 This makes it difficult to manage the GPU builds, if a separate libHYPRE.so is needed for each one. It also means build-time testing would not be possible (but that's effectively the case anyway, building for a GPU without that GPU being present). A general observation is that the infrastructure for GPU usage is not fully mature yet, which impedes general package builds. For comparison capabilities of CPUs within a given architecture family can be inspected at runtime e.g. checking for avx512 availability. simd (xsimd) usage uses this runtime capability. The GPU situation is more like multiple families of CPU architectures, amd64 vs arm64 vs ppc64le etc, which means building for all GPUs separately gives an N×M profilation of library binary files. cmake itself allows for multiple GPU architectures listed in CMAKE_HIP_ARCHITECTURES, so possibly hypre is making it more complicated than other libraries by allowing only one GPU arch at a time.
