> And worse, different binary slices are used between different dies of the same product line. As an example, for RDNA2, ROCm math libraries are compiled only for Navi21. This means that on a (smaller) Navi22 die (notably present in the 6700 XT), those components aren’t functional. The workaround is manually recompiling ROCm with support for more targets. Such a roadblock is very discouraging for adopters – and does complicate application distribution too.

holy shit I didn't realize the portability story was that bad, it can't even target a whole uarch/family at once (eg target all RDNA2) and it has to know about every specific die it will ever run on?

yeah I mean that's the deep deep problem with ROCm is there's no equivalent to PTX, AMD just wants you to distribute source and recompile everything at runtime, everything about ROCm pushes you towards source distribution rather than any kind of bytecode/IL or gosh even an executable file you could actually just run.

On NVIDIA the support story is simple: the driver does the final translation from PTX to assembly at runtime, so, as long as there is at least one overlap in the PTX versions packaged in the app and the PTX versions supported by the driver, it runs.

In practice this means you can take a program that was compiled for a CUDA 1.0 GPU (tesla uarch) and it'll run today on an ada, no questions asked. You might be leaving performance on the table by not fully exploiting the newer uarchs, but it'll run, just like x86. And you can take a program today and compile it against CUDA 1.0 capability targets (as long as it doesn't use any features that don't exist in those older versions) and the full 2023-era software toolchain will all just magically work on your 8800GTX even though driver support for that hardware has been dead for 10+ years. Because the driver knows how to run PTX 1.0 and the toolchain knows how to build PTX 1.0, and that's all that matters.

ROCm has always really struck me as being aimed at the HPC market - only supporting pro-tier GPUs, focusing on users who are already running custom software, openly disdaining amateur support, etc. And frankly the distribute-as-source model makes ROCm just a complete nonstarter for any sort of commercial or other model where the vendor would absolutely be distributing libraries or a compiled application, let alone trying to wrangle dumb customers through getting a working ROCm environment. Which right now is the authentic "linux in 1995" level experience/ordeal.

Getting serious would be restarting the GPU Ocelot project and going after PTX compatibility. But a corporation is never going to accept being a client on someone else's platform, just like they won't support the open-source Streamline framework because something something 'pluggable frameworks and library code are anti-user-freedom'. Same thing there too, AMD will only support FSR in statically-compiled code and they expect everyone to recompile all their shit and validate and push updates for every single game, every time AMD releases an update, because it's inconvenient for AMD's corporate strategy.

https://youtu.be/8ve5dDQ6TQE?t=974

(oh and now that they finally have the ML hardware, the rumor is they're working on their own ML-based upscaler, quelle surprise that the "gosh we would never do anything that legacy users couldn't run" was just a bit too.)

AMD doesn't want user freedom, they want to be the one with the leash. That's why they do the source-distribution-only model... you'll have to work with your code in the ROCm ecosystem and not NVIDIA's. You'll be compiling against HIP and not NVIDIA's stuff. Etc etc. It's not a zero-effort thing to leap the gap, and they want to keep you once you do it, you'll have the same leap to get back out.