Hi Ludo', Ludovic Courtès <l...@gnu.org> writes:
> They’re currently unable to help, so my plan was to (1) finish the > upgrade they started working on¹, and (2) polish and move all the > packages to Guix proper. > > I made some progress on (1) before going on vacation but haven’t been > able to resume since. If anyone’s interested in ROCm/HIP, let’s work > together on this! I recently updated my ROCm channel [1] (which was originally forked from the packages in the Guix-HPC channel) to version 6.4.2. It only contains packages for one ROCm version, which I think is more suitable for Guix proper. It also contains packages like composable-kernel and miopen, which are required by pytorch. Maybe that would be an easier starting point? The supported GPU architectures are defined as a package property and can be specified transitively with `(@ (guix-rocm packages rocm-base) set-amdgpu-targets)` (which uses `package-mapping`). I think your proposal for parameterized packages [2] would be suitable to specify the architecture more conveniently using the command line. I'm not sure what the default architectures should be though, as the build time for some packages (like rocblas) is already quite long for just one architecture. Also, not all packages (like hipblaslt) support all architectures. It might be a good idea to let CI build the packages for each architecture separately, so that one only needs to download the packages built for the relevant architecture. WDYT? There are still a few bundled libraries and some parts expect the whole installation to be in the same tree (like the CMake HIP language support, for which ROCM_PATH needs to be set), so that would still need to be improved. Cheers, David [1] https://codeberg.org/dtelsing/Guix-ROCm [2] https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00312.html
