It’s gone quite a lot better but still cumbersome in many aspects. They need to get some dedicated maintainers in the main ML FOSS projects to make new ROCm versions available easily.
Every time a new ROCm version is released, it takes ~2 months to have all the stars lined up and builds available for the most commonly used LLM stacks.
Backported ROCm builds should be a thing to. Doesn’t help that there’s some ROCm7 Pytorch 2.2 nightly builds when most projects still use 2.1 and are stuck with ROCm6 (esp. when AMD devs essentially push you upward to solve any problem/crash you may have).
Also, although I completely understand the need to settle somewhere in terms of kernel / distro support when it comes to Linux, it’s too bad their highest supported kernels are 6.2.x.
It’s gone quite a lot better but still cumbersome in many aspects. They need to get some dedicated maintainers in the main ML FOSS projects to make new ROCm versions available easily.
Every time a new ROCm version is released, it takes ~2 months to have all the stars lined up and builds available for the most commonly used LLM stacks.
Backported ROCm builds should be a thing to. Doesn’t help that there’s some ROCm7 Pytorch 2.2 nightly builds when most projects still use 2.1 and are stuck with ROCm6 (esp. when AMD devs essentially push you upward to solve any problem/crash you may have).
Also, although I completely understand the need to settle somewhere in terms of kernel / distro support when it comes to Linux, it’s too bad their highest supported kernels are 6.2.x.