[Slackbuilds-users] AMD ROCm SlackBuilds

[414N]

Greetings,


last summer I started working on SlackBuild scripts for AMD ROCm to play 
around with some AI stuff/Blender. I based my work entirely on the Arch 
PKGBUILD scripts (thanks Arch maintainers) and finished packaging all of 
them only recently. These are 33 packages in total, where 2 (half and 
python3-cppheaderparser) are external dependencies currently missing on SBo.

I tested the runtime mainly against software using pytorch-2.1.6, ollama 
and Blender[1] and found that it seems to be working properly on my 
RX590 card (Polaris/gfx803 architecture).

I'd like to share them with anyone interested to test them out, possibly 
with an AMD GPU.

You can find them on my `rocm-5.5.1` branch on github[2]:

https://github.com/414n/slackbuilds.org/blob/rocm-5.5.1

The ROCm version I packaged, as you can see, is version 5.5.1. I know 
it's not the latest one, but I'd like to do a version bump after having 
published all of this on SBo.

There's a top-level "rocm_packages.list" that contains all the packages 
to build in the (I hope) correct order and also a "README_rocm.md" with 
some additional notes and TODOs.

Please do read the attached READMEs to every package, as there are some 
caveats for a number of packages.

I'm not currently sharing any prebuilt package (but will hopefully do 
someday) because I took some shortcuts with some packages i.e. building 
them only for my GPU target and not the others to hasten the build process.

I'd like to ask admin/maintainers what are the best practices regarding:

  - location: I've currently put all the ROCm packages under the 
"graphics" section. Is this correct or should I change it?
  - ROCm "standard" prologue in README/slack-desc: initially, I've put 
the same prologue explaining what ROCm is in every README/slack-desc but 
grew tired of it after the first 20 packages or so ^_^. The prologue is 
this:

 > ROCm is a brand name for the ROCm open software platform (for software)
 > or the ROCm open platform ecosystem (includes hardware like FPGAs or
 > other CPU architectures).

    Should I put it in every package description or is this not necessary?
  - parallelization: some packages can build different GPU target files 
in parallel, but I observed that the number of jobs running concurrently 
is MAKE_NUMJOBS **times** this number, so running "make -j8" with 8 
parallel jobs for HIP targets results in a system under heavy load. Do 
we just ignore this possibility altogether or make it optional with a 
note in the README?
  - Polaris/gfx803 support: this generation is not officially supported, 
however by forcing some build flags or with trivial patches this support 
can be easily re-enabled and, from what I've seen on my own GPU, it 
seems to actually work okay. Both Arch and Debian[3] packages do enable 
back support for this generation of cards, so I'd do the same. What do 
you think about it?


Kindest regards and happy new year everyone!


[1]: Blender 3.3.10 requires some "persuasion" to work with a gfx803 
card: a patch when compiling it to re-enable working on GFX < 9 
era-cards and a pre-compiled and patched hip kernel for Cycles, 
otherwise all the rendering gets black

[2]: the branch actually contains some WIP scripts/TODOs that I plan to 
remove when all the issues are resolved.

[3]: https://lists.debian.org/debian-ai/2023/03/msg00050.html

-- 
Alan Alberghini

SBo clone: https://github.com/414n/slackbuilds.org