Radeon ROCm 5.0 Released With Some RDNA2 GPU Support

[flavonol]

The ROCm stack up to OpenCL on RDNA 1/2 has been included in the AMDGPU-PRO driver packages for over a year - it's the math libraries and ML framework support (which have optimized assembly code for each GPU) that are still under development.

I see. I've been relying on the ROCm docs for installation instructions (which didn't work properly for me last time I tried, although that was a while ago) and the table of supported GPUs.

I believe our range of supported distros is actually a bit wider than Intel's ...

Looks like you're right in the sense that older versions of Red Hat/CentOS & SUSE are supported, although NEO currently appears to be packaged for more distributions. I recognize that being packaged for a distribution ≠ support for said distribution, but it is nice.

... although I expect both will continue to grow as a consequence of current distro packaging/integration efforts.

I hope your expectation is right. I'd especially appreciate Fedora Workstation support, as it's more up-to-date than Red Hat and happens to be what I use currently.

[Maxzor]

Thanks, if there any instructions how to install it on Debian Testing? I tried a few .debs and dependencies escalated quickly to a package which is not present in AMD repository, nor in my system.

which package?

[vegabook]

Is it though? I am not sure that the metaverse thingy or even just web usages cater to all the compute needs in the world, eternal debate... And vulkan compute still seems to have big issues? The landscape is very complex and moving fast, so it is hard to have both an accurate and complete view of it.
Yet you seem to me like deploying quite some energy into telling the story that ROCm is trash in these forums. I might be too much on the opposite behavior, oh well

BIg "vertical" stacks for sure cannot use consumer APIs like Vulkan or WebGPU. Think the machine learning frameworks. robotics, video processing etc where libraries built by the manufacturer on their own stack will always give much deeper and efficient access to the hardware's capabilities. Think CUdnn, Cublas, Rocblas all this sector-specific stuff. But take a vector programming language like R, Numpy, or even emergent vector languages like Futhark or BQN, these are generalist vector languages which can easily target a smaller cross platform abstraction which I believe WebGPU and Vulkan can enable quite easily.

My beef with AMD is indeed perhaps a bit obsessive, but I have been burned hard by ROCm having wasted years waiting for it to be usable from a consumer standpoint, only to be serially disappointed and I don't see much here in V5 still that will democratise GPU compute access. Nvidia gets a lot of flak for its closed-source strategy, and I don't like it either, but at least it doesn't stupidly segment the market trying to make it hard for consumers to do GPU compute (FP64 aside). I keep reminding in these forums, that the exact same Cuda stack works perfectly, out of the box, from a 100 000 USD DGX cluster, right down to a 59 dollar Jetson Nano, and including all the GTX/RTX cards in between. It is this ease of access which has made it dominant, to my open-source chagrin.

[Maxzor]

I agree with everything you said there^. I have been near the stack for two months while packaging it and have beefs too.
I recently got in touch with various engineers at the Exascale Supercomputing Project (ElCap, ANL...) from spack's slack, and while AMD has only eyes for them as if they were their golden goose, even at the ESP they are telling AMD to care about wider distribution of the stack through Linux distributions...
Probably some dysfunctionings in the upper management, or at least questionable strategic choices, given how much more cards they could sell to prosumers & consumers. In my opinion it is AMD engineers, volunteering to do the work with distros, while not being fully approved by their hierarchy, that will save the success of the stack, if it's not too late.

[piorunz]

which package?

hsakmt-roct

[ernstp]

Uhm, what?

"You have searched for packages that names contain rocm-opencl in all suites, all sections, and all architectures.
Sorry, your search gave no results"

Yeah I mean that as a slight tweak to the ROCm install instructions! If you follow them you will see what I mean.

[ernstp]

hsakmt-roct

Ubuntu 22.04 is based on "bookworm/sid" so it should be pretty similar, though it's not exactly the same of course.

Did you do "apt install rocm-opencl" like I suggested?

[vein]

Thank you AMD, works perfectly on my old Fury card
(Easiest way to install on Arch is the opencl-amd package from AUR)

[Maxzor]

hsakmt-roct

One thing sure is that this package is the thunk, the very basis of the stack userspace-side.
You might want to read thoroughly the official install instructions again as mentioned. But they might be broken too, no clue.

AMD allows either to download from its site a tarball, containing all the binary deb. packages, and then to add your extracted-tarball-local-dir to the list of apt sources; or it allows to add to your apt sources directly something like https://repo.radeon.com/rocm/apt/5.0/ .

I did not use AMD packages (nor its metapackages like the *toolkit.deb ones) within last two months, I try to follow and map their names to the incoming official debian packages to manage future conflicts and updates (they are not ready yet, soon!), you can find this WIP mapping here, which reads (last time I checked really, contributions welcome) :

hsakmt-roct-amdgpu

[LumielGR]

Thank you AMD, works perfectly on my old Fury card
(Easiest way to install on Arch is the opencl-amd package from AUR)

Man, you are fast, I haven't even released the package yet :P