Bug#882667: hypre: CUDA support: hacks impeded by -W flags

[Drew Parsons]

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.