Hello everyone,
This may be a tangent with the ROCm upgrade to 6.x, but I think an
improvement that would be greatly appreciated by many people using
Blender on Debian Stable would be to have a backported 5.7
version. The problem with ROCm 5.2 is that Blender-wise it only
supports Vega64 and Vega II and only in two older Blender versions
(3.5 and 3.6). And since Vega II has been disabled in Blender
since version 3.6, the only working AMD GPUs in Blender on Debian
Stable are basically Vega64.
None of the NAVI GPUs can run in Blender with ROCm 5.2. According
to the official Blender documentation [12] - the minimum required
version of ROCm is 5.3 (Adrenalin 22.10).
In the hackernews thread [13] Christian K. have mentioned that
there is a plan to backport ROCm 5.7 to bookworm. I think this is
a great idea at least for Blender users. The needed package is
`libamdhip64`+ dependencies.
As always - thank you for your work.
Best regards,
Jakub Jaszewski
[12] https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html
[13] https://news.ycombinator.com/item?id=37663194
Apparently the subscription request isn't going through... I tried a few times.
I tried making a gitlab account for Salsa, but looks like I'm also not getting confirmation emails from there either... I swear I checked my spam folder.
> If you're unfamiliar with Debian packaging
So the packaging itself I'm familiar with, it's more of the practices and policies that are a bit opaque to me. E.g. how legal review works, what is best practices for naming and source handling, etc.
I gave the list of packages that I'm most familiar with, so I hope to help out there with updates and hopefully that would take some load off of you guys to focus on the other stuff.
> correctly assess the notable changes
Fortunately because I work on Fedora packages, I do this already, so I feel like I can help out there. Someone would need to check over my work though to make sure it's kosher, but I can do the heavy lifting.
For reference, Tom Rix (of Redhat) and I are currently the main maintainers in Fedora, and I tend to focus on the lower end, while he handles the higher math libraries.
> There's also an ABI breakage [6] to deal with ...
So prior to 6.1, ROCm just targeted their own fork of LLVM, which was always misaligned with upstream LLVM API/ABI.
Starting 6.1, they are choosing an LLVM branch during development to align their LLVM with, so in theory breakage should be minimal if we match that LLVM branch.
ROCm 6.1 targeted LLVM 17, 6.2 should target 18, while my best guess is that 19 should be around 6.4 or similar timing, depending how many releases they do this year.
The "amd-mainline-open" branch is a preview of the next ROCm release, and it appears to use LLVM 18 [9], hence why I suspect 6.2. We can get a good idea when the switch to LLVM 19 happens when this branch changes. They have a staging branch as well that they use as staging new llvm changes before merging into their mainline [10]
As I meantioned, ROCm 6.1.2 broke due to API, but this is a bug, I've documented it [11]
> That depends on how deep you want to get into Debian packaging.
My gut says that if I can send a merge request on Salsa for upgrades for the packages I'm familiar with, I think that's my best way to contribute. We can figure out the detail during review, as I learn quicker on the job. I assume this is ok, right?
> Just one example: regarding MIOpen
Yeah I'm not 100% sure how to handle miopen, I've been too preoccupied with maintaining the lower bits that I've been out of the loop. I can sync up with Tom Rix about how fedora is handling it.