AMD Preparing ROCm 6.1 For Release With New Features

[phoronix]

Phoronix: AMD Preparing ROCm 6.1 For Release With New Features

It looks like AMD will soon be announcing the ROCm 6.1 update to its open-source GPU compute stack...

https://www.phoronix.com/news/ROCm-6.1-Release-Coming

[darkbasic]

GPU and CPU support is so extremely limited to make it useful to just a handful of people. I'm personally still waiting for ppc64le support: https://github.com/ROCm/clr/issues/61
Rusticl works on ppc64le.

[NeoMorpheus]

Here just for the complaints.

[Eirikr1848]

Here just for the complaints.

Where’s ZLUDA?!

[NeoMorpheus]

Where’s ZLUDA?!

Check with Dear Leader Jensen why he didnt make cuda open source instead of being locked to his hardware, since zluda has proven that its artificial lock-in.

[aufkrawall]

Still getting zombie processes + amdgpu errors logged in dmesg with ROCm & OCL activated in LibreOffice on 7800 XT.
And RustiCL still turns LuxMark into a zombie when compiling its compute kernel.

[timofonic]

I respect AMD and its workforce, and I appreciate their efforts and innovations in the GPU market. However, I have some reservations about their current strategy.

Market segmentation can limit their growth potential as a challenger, while Nvidia offers GPU compute support on most of its consumer cards.

I think AMD should hire more developers for this and improve AMD GPU support in many software out there.

I wonder when AMD will support all consumer cards, as Nvidia does. I have asked AMD engineers about this, but I always get the same canned responses.

I hope they reply and their bosses reconsider their current strategy, which I find ineffective and frustrating in terms of missed opportunities.

bridgmanagd5f

[pWe00Iri3e7Z9lHOX2Qx]

Here just for the complaints.

I've now bought around 10 RX 5700 / RX 5700 XT / RX 6700 XT / RX 6750 XT GPUs. I don't think it's unreasonable for me to want those to be fully supported by AMD's GPU compute framework, and for that framework to be easy to set up on enterprise backed distro. NVIDIA set the bar here many years ago. AMD deserves all the ridicule they get for ROCm.

[agd5f]

I respect AMD and its workforce, but I have some reservations about their current strategy.

Market segmentation can limit their growth potential as a challenger, while Nvidia offers GPU compute support on most of its consumer cards.

Also, they should hire more developers for this and improve AMD GPU support in many software out there.

I wonder when AMD will support all consumer cards, as Nvidia does. I have asked AMD engineers about this, but I always get the same canned responses. I hope they reply and their bosses reconsider their current strategy, which I find awful and agonizing in terms of missed opportunities.

bridgmanagd5f

The support is there in the compiler and most libraries for all of our GPUs. It mostly comes down to validation. We don't mark chips as supported in the official releases if they have not gone through a full ROCm validation cycle. It's similar to mesa. We include mesa in our packaged drivers, but we only claim support for the chips that were validated, however most users get mesa from their distro, so it generally just works and no one pays attention to what's listed as supported or not in our official packages. I think you see something similar once more distros start to package ROCm. We've been working extensively with Debian, Redhat, etc. to provide native packages for the respective distros. E.g.,
Fedora: https://fedoraproject.org/wiki/Changes/ROCm6Release
Debian: https://salsa.debian.org/rocm-team, https://lists.debian.org/debian-ai/

[DiamondAngle]

The support is there in the compiler and most libraries for all of our GPUs. It mostly comes down to validation. We don't mark chips as supported in the official releases if they have not gone through a full ROCm validation cycle. It's similar to mesa. We include mesa in our packaged drivers, but we only claim support for the chips that were validated, however most users get mesa from their distro, so it generally just works and no one pays attention to what's listed as supported or not in our official packages. I think you see something similar once more distros start to package ROCm. We've been working extensively with Debian, Redhat, etc. to provide native packages for the respective distros. E.g.,
Fedora: https://fedoraproject.org/wiki/Changes/ROCm6Release
Debian: https://salsa.debian.org/rocm-team, https://lists.debian.org/debian-ai/

Idk thats not really true, theres a lot of stuff like https://github.com/ROCm/rocBLAS/blob...handle.cpp#L76 that calls out specific llvm targets in various rocm libraries. Theres also alot of custom kernels that are asm and device specific that exist only for supported chips, sometimes with no generic fallback like in ck. Sure sometimes there IS a generic fallback, but not always. Theres also the issue that since you have to compile everything for each llvm target and that unsupported targets arnt compiled for by amd or distro packages often, leaving those users to compile the entire rock stack, which is certenly a journey that really is not easy - i speak from expirance.