HIP Library, main branch (2025.11.13.)

[krasznaa]

This all started out with me trying to see if CoPilot would be able to do all of this automatically / by itself. Unfortunately that all worked very poorly, so I rather did the whole migration by hand in the end. 😦

But still, I wanted to start making a traccc::hip library finally.

To start things off, I converted traccc::cuda::clusterization_algorithm into a traccc::hip::clusterization_algorithm. Code-wise it was pretty much a copy-paste, with a cuda => hip replacement applied. The only tricky part was to convince the build system to behave more or less reliably.

Which for me specifically it by now does. But I'll need some additional eyes as well. @StewMH, please have a look. Specifically at what ( did to the setup of rocThrust. As it was giving me a world of hurt. 😦

For now I didn't do anything specific to the CI setup. But (for me a bit) surprisingly TRACCC_BUILD_HIP is already exercised by the "ALPAKA HIP SYCL" build. 😕 @StewMH, should we take things a bit more apart? The Alpaka build should really only test builds through Alpaka. I'd rather test the build of "native HIP code" in a separate CI job. Or rather, ideally we'd add 2 new CI jobs. One building the HIP code with its AMD backend, and another one using the NVIDIA backend. As one can very easily break either one of these without breaking the other. 😦

[StewMH]

Hi Attila,

Great to see this. TRACCC_BUILD_HIP is enabled for Alpaka-HIP so that the rocThrust tests are also built. Didn't seem worth having its own build just for this, but now that we have all this code it definitely makes sense to test it properly.

[stephenswat]

We need to have a serious conversation about the number of backends that we have now. If this PR goes in, we have four different methods of targetting AMD GPUs (HIP, Kokkos, Alpaka, SYCL), or which three (HIP, Kokkos, Alpaka) deliver exactly the same code to the ROCm compiler and can therefore, almost by definition, not lead to any meaningful performance benefits.

As with all the backends for traccc, this puts the maintenance burden on the people actually developing the algorithms. We've gone from having to duplicate all our changes twice to three times to four times and now to five times. It's not a sustainable development model.

[StewMH]

Alpaka and hip tests work fine for me, without getting into bigger issues.

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
22.4% Duplication on New Code

See analysis details on SonarQube Cloud

[krasznaa]

Unfortunately I was having a very difficult time building traccc::hip::kernels::ccl_kernel using ROCm 6.2 on Ubuntu 24.04. (It's a weird incompatibility between ROCm 6.2's version of clang and the GCC 14 version that it finds on my private machine.) But with ROCm 7.1 the build succeeds happily. So as long as the CI is happy as well, I don't want to complicate things further.

So... 🤞

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
11.7% Duplication on New Code

See analysis details on SonarQube Cloud