just doesn't hold up if you look at the marketing material for the Radeon VII Pro. There are jobs that it is supposed to handle as a product and those should be(come) available.

This is insane, the REASON Nvidia has so much mind share... is you CAN buy old GPUs and learn on them, and that translates directly into writing CUDA code for HPC.... do you expect college students to buy MI350X next year instead of writing code for MI60 which they can afford easily?

Largest is the number of hardware that support an API, greatest is the incentive to include the support for that API by third parties’ developers and industry. Obviously if an API works only with a small combination of hardware and software, there is less interest to invest resources and time to support a niche. Most developers and companies will not go to buy new AMD Instinct GPUs just for the sake to work on ROCm, that is less popular and mature than CUDA, with the fear that such hardware may be also become unsupported in few years as happened to AMD Instinct MI25 based on GCN 5.0, it is AMD that have to make it as accessible as possible to maximize people involvement, confidence on long term support and push its diffusion. To boost its adoption, they should have ROCm support extended to all Radeon included the ones of the GCN generation and APUs that are massively popular and with proper ROCm support would have even allowed to experiment AMD technology with LLM on very low budget using system memory in UMA mode; and despite performance level cannot bee optimal also on older and\or weaker GPUs, still the gargantuan user basin gained would benefit the whole AMD ecosystem.

Reposting an opinion from Phoronix that quite well summarizes my stance on hardware support on ROCm. https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1508304-amd-talks-up-imminent-rocm-6-3-with-big-performance-gains-new-features?p=1508586#post1508586

This is f***ing shameful AMD. Card support is the biggest thing that separates you from CUDA. Card support is the one big reason devs don't want to go fucking near your stack unless bean counters come down from on high and force it as the "bang for buck" option. Card support. Card support. Card support.

Nvidia supports SEVERAL GENERATIONS of cards with CUDA, across both enterprise and consumer cards. Devs prototype apps with consumer cards, deploy on enterprise cards. It's not rocket science. If your stack doesn't run on the cards people have, they won't run it.

You need to support ROCm, officially and with no compromises, on every market-relevant consumer card and enterprise card. It would be absurd for a game studio to say "sorry, we're dropping support for our game on the nvidia 30XX series now that 50XX is coming out" when there are even lots of 20XX cards around. Furthermore, this asinine bullshit of "well maybe this card works, the code is still there for it but it's not official" has to end. Today. The only reason I think AMD can't bring themselves to draw a hard line in the sand and drop code for cards they don't officially support is it would reveal just how vanishingly small their support pool actually is.

As far as I'm concerned. ROCm is dead on arrival to me. I will never, ever use it, no matter how much you improve performance, no matter how many features you add, unless you address this massive gulf of support. The ROCm compute stack does not exist. I have to assume that no matter what card I have, it is either not supported or will be broken by a change tomorrow. I patiently wait for MESA to do your job for you and get rusticl together, providing the reliable, works-on-every-card experience you do not comprehend the importance of.

PS. I'm sorry you did something stupid and didn't implement an equivalent of nvidia's PTX (or any standard intermediate representation) and instead required apps to compile down to specific cards, if that is indeed a limiting factor. Maybe you should think about implementing that if you want to ease your own maintenance burden and the burden of people attempting to support you.

Unless AMD addresses those issues seriously I'd rather root for any other alternative that be NVIDIA opensourcing their driver stack, Intel pushing oneAPI, Vulkan compute or anything else that can give us working compute stack on Linux. Even thou I have AMD GPU in my own Linux machine, when it came to advising purchases for an institution that I work for I advocated for NVIDIA specifically for the reason explained above.

RDNA4 is on ROCM 6.3. AMD starts with 4 gpus rdna3 support, 7900XT, 7900XTX, 7800 AI, 7900 AI.
They are done big steps in last year, and they are working parity between linux and windows, and support more distros.
Rocm6.3 is coming but rocm7 comes with unified stack.

RDNA4 is coming with sistolic arrays, so it will be a big improve for inference. RDNA5 will be UDNA
https://www.phoronix.com/news/AMD-ROCm-6.3-Features

A hodge podge of releases that "support" the range of GPUs.... is very cumbersome. AMD needs to start being about we make things work NOW, rather than wait till next release. All the GPUS of the last decade need to work now under one roof.

A hodge podge of releases that "support" the range of GPUs.... is very cumbersome. AMD needs to start being about we make things work NOW, rather than wait till next release. All the GPUS of the last decade need to work now under one roof.

I understand your part, but I think the previous ranges have very poor performance, even rdna3 in computation and in inference is not too good. Thus, the change of philosophy with UDNA. I have w7900 dual slot

@johnnynunez please refrain from quoting the entire post of someone you just want to respond in a general way!

RDNA4 is on ROCM 6.3.

Have you at least read the message I quoted and what I have written myself? Or you are responding just for the sake of having a conversation? You are trying to make a point about future generations, I'm talking about supporting past ones.

but I think the previous ranges have very poor performance, even rdna3 in computation and in inference is not too good.

Tunnel vision response. COMPUTE =! AI. Let me repeat this: COMPUTE =! AI

You clearly do not take into account that ROCm can and IS used by software other than AI. Case in point - Blender (and hopefully many other in the future). I and many others do not care that AMD 3D rendering performance (in applications like Blender) is on the lower side as long the GPUs are cheaper and have stable driver stack. Radeons usually have a lot of VRAM and that is very useful for rendering bigger scenes even if the rendering is slower vs NVIDIA. Driver stability and platform longevity are much more important than absolute performance. This is the case for both 3D rendering market segment and ROCm developers, as it was stated in the post I quoted.
For the record, aside from using Blender I also use ROCm for AI inference. And I will even argue for the platform stability and longevity for DAW, CAD, medical, etc, folks as well even I'm not using their software myself!

Sorry for the harsh tone. It's not personal. I have very low tolerance for meandering discussion style and ignoring the fundamentals for the sake of the hype.

That is good to hear actually.
Just out of curiosity is IR relatively stable and different ROCm versions compile to IR in a way that it can be run on any GPU that can process that IR? Is this what NVIDIA did with forcing OptiX to run on CUDA cores by compiling to PTX that can be understood by a GPUs that do not have Tensor cores (like 1080ti)?

That would work with the SPIR-V based approach, yes. The "generic" targets are still machine code like before, and so they wouldn't. I guess its just a subset of the instructions that each GPU in the generation supports, if there are any differences...

Requested an intermediate bytecode in #3985 and it was closed as not planned.

#3985 (comment)

Sorry about that, you are correct, there is work in progress to support compiling down to an AMDGCN flavoured SPIR-V. However, this will be a secondary option alongside the existing approach to compile down to ISA (which provides better optimization and lower overhead at runtime as mentioned above) rather than a replacement, so users will be able to choose between compiling to ISA or to SPIR-V.

Hi @Snektron, came across this discussion by accident.

I guess its just a subset of the instructions that each GPU in the generation supports, if there are any differences..

You guessed right. Pop up https://llvm.org/docs/AMDGPUUsage.html and Ctrl+F "Target Restrictions" which will show you what features are lost on each of the gfxY-Z-generic targets. I too thought it's nuances only, but they are mostly pretty serious: losing VGPRs, losing important instructions (SALU floating ops, one of the selling points of the generation)... at this point I'm not entirely sure these generic targets make any sense. I too hope that the SPIR-V stuff land sooner, rather than later. I have both the comgr folder and clr/rocclr/device/device.hpp bookmarked to monitor SPIR-V progress and the hopeful landing of cl_khr_il_program.

It can't come soon enough. Maybe add VK_AMD_hip_kernel_launch while they're at it. (Or just expose the NV variant, although that's a grossly underdocumented feature. It's also absent from vk.xml, so it's hard to meaningfully extend its API with AMD-specific structure types.)

This people is just plain nuts. Quite a good example of enshittification.

Those gfx900 are RX Vega 64 from 2017-20 (GCN 5.0) and the gfx906, MI50/MI60 from 2018-2022 (GCN 5.1)

| reduce the increasing size of ROCm binaries.

Who in the earth will complain about that, lol🤨?

It would be even better if it just worked ... as in generated whatever the optimal code that could run on a given GPU by default instead of disabling things by default and making things hard for no reason. Acutally that's what every other API/SDK out there I have ever seen does....

gfxX-generic finally fixes this, at lest when everything finally switches over to that...