Hello again,
Please enjoy your trip, Étienne! I know you probably won't have a chance to take a look at this until next week or later, but I thought I'd share my experience while it's fresh in my mind. Below are the changes to the Debian HIP packages that were required for building rocRAND.
In hipcc:
1. The addition of -isystem "$HIP_CLANG_INCLUDE_PATH/.." to HIPCXXFLAGS and HIPCFLAGS
needs to be removed from hipcc [1]. Once HIP is installed in /usr, hipcc ends up passing -isystem /usr/include, which breakes the
proper order of C and C++ include paths. If I understand
correctly, it's unnecessary for hipcc to pass these flags anyway.
A patch to remove them will eventually be made upstream.
In hip-config.cmake:
2. I'm not sure how it happened, but I encountered an improperly escaped quote in hip-config.cmake on line 274 (after AMD_DEVICE_LIBS_PREFIX). It might have been my imagination. The code looks fine in the template [2].
3. A few relative paths need to go one directory further down. I'm not sure why. Maybe it has to do with defining LIBDIR as lib/<multi-arch>? In any case, the PACKAGE_PREFIX_DIR defined on line 27 of hip-config.cmake needs one more "../". Though, that seems to come from CMakePackageConfigHelpers [3], so I'm not sure why it's inaccurate.
4. The _IMPORT_PREFIX needs an extra "../". It appears in the template at line 186 [4].
5. The INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_SYSTEM_INCLUDE_DIRECTORIES are incorrect, but can be fixed by removing a ".." from their definitions. In the template, these are on lines 218-219 [5].
6. The device libraries are not found correctly by default and
the if (NOT EXISTS
${AMD_DEVICE_LIBS_PREFIX}/amdgcn/bitcode) check is
triggered [6]. I think the goal upstream is to eventually remove
this from the hip::device interface
entirely, but for now just correcting the search paths would be a
good step.
There's still a few mysteries to track down with regards to the HIP package, but these are pretty minor issues! It's great to see that with a handful of tweaks, we have something usable.
With respect to the packaging of rocRAND and the rest of the math
libraries, I don't think it's worth worrying about them too much
quite yet. We can take a look when ROCm 5.2 is released, but there
was a lot of turmoil with the file layout reorganization. In ROCm
5.2, my focus was ensuring that the new layout was available and
that the backwards-compatibility symlinks and headers worked.
Debian will want to build with
-DBUILD_FILE_REORG_BACKWARD_COMPATIBILITY=OFF and I
suspect you will find a lot of minor issues because that
configuration has not been tested. Many of the libraries will
probably themselves depend on the backwards-compatibility headers
and symlinks until ROCm 5.3.
[1]:
https://salsa.debian.org/rocm-team/rocm-hipamd/-/blob/upstream/5.0.0/hip/bin/hipcc#L191-192
[2]:
https://salsa.debian.org/rocm-team/rocm-hipamd/-/blob/upstream/5.0.0/hip-config.cmake.in#L240
[3]:
https://github.com/Kitware/CMake/blob/v3.23.1/Modules/CMakePackageConfigHelpers.cmake#L295
[4]:
https://salsa.debian.org/rocm-team/rocm-hipamd/-/blob/upstream/5.0.0/hip-config.cmake.in#L186
[5]:
https://salsa.debian.org/rocm-team/rocm-hipamd/-/blob/upstream/5.0.0/hip-config.cmake.in#L218-219
[6]:
https://salsa.debian.org/rocm-team/rocm-hipamd/-/blob/upstream/5.0.0/hip-config.cmake.in#L233-242
Sincerely,
Cory Bloor