ROCm 5.5.1 Released For AMD's Open-Source Compute Stack

[qarium]

We have been supporting the ROCm stack up to and including OpenCL on consumer hardware for a couple of years - it's the higher level components, particularly the math libraries (which use a lot of shader assembly code) that have required more effort and hence more time.
We don't make that as clear in the documentation as I would like. Will see if we can improve that.

with my Vega64 HIp/Blender never worked for me on Fedora 38 with Blender 3.5.1 and linux kernel 6.2
yes i have ROCm installed in Fedora 38... i think vega will drop out of AMD's support this year so i do not have hope that is will ever work.
but tell me why for the newest cards like the 7900XTX ? would it be not smart for AMD to make it work on the newest cards so that customers go and buy the new cards ?
but i can not see this AMD did release the 7900 cards without ROCm support
in the time of AI hype this is not a good idea people these days spend more money to run open-source AI deep learning models on GPUs than to play games.

and also please google the MEGA65 (8bit commodore 65 computer based on a FPGA) this product shows that it is time for AMD to put an FPGA on every CPU/GPU/APU... because software emulation does not work very well compared to a FPGA solution.
the 16bit Amiga Vampir v4+ standalone is also based on a FPGA solution
this means if AMD would put in a FPGA in every APU/CPU people could run such emulations of old hardware without the burden of software emulation overhead. for emulation of such old architectures and system FPGA looks much better than software emulation.

[CTown]

...would it be not smart for AMD to make it work on the newest cards so that customers go and buy the new cards ?...

Considering that media outlets and Reddit are recommending buying AMD's last gen video cards for gamers, AMD will need to focus on a different market segment if they want sales. I'm sure they are working on it as I doubt AMD's long term strategy is to let mid tier RTX cards beat $1000 Radeon cards in so many non-gaming benchmarks.

[AndyChow]

I tried. Not successfully yet. I'm owning a 5700XT it should work according to a lot of Reddit posts but I need to tinker more. Even if I have setup a dedicated distro environment to meet the requirements as close as possible it is still quite an endeavour.

If I wouldn't be keen to try it ...I would already stop trying. This is quite discouraging since I want to support AMD to break the CUDA dominance.

What's your motherboard's pcie version? Last time I used rocm It needed to be on pcie version 3, with atomic transactions enabled. I got it to run, but performance was rather weak, less than 1/3rd of what I'd get on a similar nvidia card, so I went that way. It ran on my RX 480, definitely a consumer card.

[cgmb]

We have been supporting the ROCm stack up to and including OpenCL on consumer hardware for a couple of years - it's the higher level components, particularly the math libraries (which use a lot of shader assembly code) that have required more effort and hence more time.

To be clear, the use of shader assembly code in the math libraries isn't why this has been difficult. As far as I can tell, every library has generic fallback paths. We never build for architectures that we don't officially support, so sometimes overly-specific #ifdefs creep into the code. However, I have been building and testing each library on a wide range of GPUs, and thus far every library has worked on every GPU I've tried after only minor patches.

As a math libraries developer, in my opinion, the two main reasons why we do not have full support for all GPUs in the ROCm math libraries are:

1. a. There have been 25 different GFX9, GFX10 and GFX11 ISAs that have been introduced since Vega released in 2017. A library like rocsparse is roughly 250 MiB. If it were built for all 25 ISAs, that one library would be 6 GiB. We have something like 17 libraries, so the total installed size of ROCm would be around 100 GiB.

1. b. That hypothetical 6 GiB rocsparse library couldn't actually be created. The use of 32-bit relative offsets by the compiler constrains the maximum size of a binary to 2 GiB. Any binaries larger than that would fail to link. We could create multiple versions of the library built for different GPUs and ask the user to install the version for their GPU, however, our current build and packaging system is not sophisticated enough to do that.

2. We do not have the test infrastructure to validate every library for every GPU to support the same level of quality that we do for the MI series GPUs, and we don't have any concept of tiers of support.

There are a few different solutions in the works to address (1). Many of the GFX ISAs are literally identical to each other or have minimal differences. I'm confident we will solve (1) and then the libraries will at least run on all AMD GPUs. However, they would still not be validated for correctness on consumer cards unless we also solved (2).

[qarium]

To be clear, the use of shader assembly code in the math libraries isn't why this has been difficult. As far as I can tell, every library has generic fallback paths. We never build for architectures that we don't officially support, so sometimes overly-specific #ifdefs creep into the code. However, I have been building and testing each library on a wide range of GPUs, and thus far every library has worked on every GPU I've tried after only minor patches.

As a math libraries developer, in my opinion, the two main reasons why we do not have full support for all GPUs in the ROCm math libraries are:

1. a. There have been 25 different GFX9, GFX10 and GFX11 ISAs that have been introduced since Vega released in 2017. A library like rocsparse is roughly 250 MiB. If it were built for all 25 ISAs, that one library would be 6 GiB. We have something like 17 libraries, so the total installed size of ROCm would be around 100 GiB.

1. b. That hypothetical 6 GiB rocsparse library couldn't actually be created. The use of 32-bit relative offsets by the compiler constrains the maximum size of a binary to 2 GiB. Any binaries larger than that would fail to link. We could create multiple versions of the library built for different GPUs and ask the user to install the version for their GPU, however, our current build and packaging system is not sophisticated enough to do that.

2. We do not have the test infrastructure to validate every library for every GPU to support the same level of quality that we do for the MI series GPUs, and we don't have any concept of tiers of support.

There are a few different solutions in the works to address (1). Many of the GFX ISAs are literally identical to each other or have minimal differences. I'm confident we will solve (1) and then the libraries will at least run on all AMD GPUs. However, they would still not be validated for correctness on consumer cards unless we also solved (2).

This honestly sounds like "Fraud" to me. its total irresponsible how AMD handle this.

we have 64 bit cpus for decades and we really use 32bit ???
"The use of 32-bit relative offsets by the compiler constrains the maximum size of a binary to 2 GiB"

"We could create multiple versions of the library built for different GPUs and ask the user to install the version for their GPU, however, our current build and packaging system is not sophisticated enough to do that."
.
Hell why not? why not make it like gentoo ship the source code and the people compile it for their gpu themself ?
and why not plain and simple improve the build and packaging system to serve this need ?

i think no one expects that amd do fully validate the consumer cards.
.
also if AMD can not solve the support why not drop older generations like vega? i have my vega64 from 2017 and ROCm never worked i tried multible times. if it does not work anyway why not official drop the support.

"and we don't have any concept of tiers of support"

AMD tries to sell support bundles with some PRO hardware and honestly i think this is wrong.
AMD should sell support to any AMD hardware if it is PRO or consumer cards.

how complicated can it be to make the compiler fully 64bit ?

how complicated can it be to make 1 driver per graphic cards generation instead of 1 driver for all cards ?