Right, and they are standardizing on CUDA. Something no other company has any chance of matching for the forseeable future.

How many people are writing to CUDA directly, and how many folks are using something like PyTorch front-end where the back-end can potentially be changed?

* https://pytorch.org/blog/pytorch-for-amd-rocm-platform-now-a...

* https://rocm.docs.amd.com/projects/install-on-linux/en/devel...

* https://dev-discuss.pytorch.org/t/opencl-backend-important-u...

And even with middleware, turns out CUDA has the best debugging tooling, followed by DirectCompute/DirectML and Metal.

now, for how many of those things does AMD have a pluggable backend that actually works? none of them, unfortunately. Octane implemented on SPIR-V - on NVIDIA and Apple, because those were the runtimes that worked. AMD and Intel couldn't even compile it successfully (intel probably would today, I'd guess). Blender tried to support AMD for a long time, and the runtime was so buggy and defective they eventually pulled support from OpenCL entirely, since the OpenCL only ever ran properly on NVIDIA and Apple, and both of those have alternative interfaces that are cleaner and faster. The only point was supporting AMD, and AMD's OpenCL implementation is so buggy that it ended up being a de-facto AMD-specific codepath anyway.

That's the problem, AMD's software stacks are fractally broken. Not just HIP and their oneAPI adapter, but the ROCm it runs on. Not just ROCm, but the OpenCL it runs on. Not just openCL, but the kernel scheduler it runs on. Everything is broken at every level even on supported hardware.

Saying "it's just software" is a handwave. There are literally entire stacks here that are not fit-for-purpose and need to be substantially rebuilt before you can start building the layers above them. There isn't a stable enough basis to just implement an adapter for these pluggable frameworks, because the runtime and the kernel code are also broken.