AVavcxz·Sep 28, 2023
I can totally understand your frustrations, considering the rocm-arch team/community has been seeing these (and trying to fix them) for years now.
I urge you to post any problems you face on the discussions page [1] for the rocm-arch community. Just to get more visibility and to add to the corpus for others to see (or even just to complain and have a voice heard, lol).
[1] https://github.com/orgs/rocm-arch/discussions
So for integrating rocm support into packages, typically this is done by specifying rocm as a build flag. Thus, even if the project supports rocm if it hasn't been built for rocm targets, it won't work on rocm platforms.
For blender and python-pytorch, contributions were made to the Arch Linux build recipes so that they have rocm support, I'm not sure about darktable. For python-torchvision, see [2] to use a rocm build of it
Read the rest
. Maybe that helps?
[2] https://aur.archlinux.org/packages/python-torchvision-rocm
Edit: this doesn't seem to be the case for darktable. Maybe wait for rocm 5.7? idk [3].
[3] https://github.com/ROCm-Developer-Tools/clr/issues/3#issueco...
Feel free to request rocm builds of packages on https://github.com/orgs/rocm-arch/discussions.
Others have discussed other issues such as gfx1032 not being officially supported and the fact we are packaging the source from amd repos so the experience may not be different than on other platforms.
I will say though that just having an independent team aside from AMD to build and ship rocm is definitely great for the rocm community. Get the product out in the audience for more real world feedback to provide back to the rocm project and make it better. The rocm-arch folks have made several upstream contributions to rocm.
Definitely, excited on the progress of the Debian team and we've been keeping an eye on each other's progress. https://github.com/orgs/rocm-arch/discussions/674