ROCm is doing excellently at pursuing the opportunity AMD is interested in. It's running on seriously fast supercomputers doing useful stuff for customers. I th

ROCm is doing excellently at pursuing the opportunity AMD is interested in. It's running on seriously fast supercomputers doing useful stuff for customers. I think it's also running production machine learning workloads though I don't pay much attention to that. AMDGPU in general is doing brilliantly in games consoles and, as far as I can tell from the outside, roughly holding its own in PC gaming. ROCm as a Linux first, open source lets-do-maths-on-GPUs is not being pursued to the same extent. That's evident in the supported hardware list (which is essentially the cards in supercomputers) and that the ROCm stack that comes in binary form hasn't been compiled for various gaming cards. Arch and I think Debian have packaging efforts in place for it, and with determination it's possible to assemble working toolchains from source code. It's not easy to build a working system out of exclusively open source code and amdgpu gaming hardware but it can be done. The challenge is that the linux kernel, ROCm libraries and LLVM toolchain all need to broadly agree on ABI at a given point in time, and that interface changes more often than one would like, and not simultaneously across the projects. That's the sort of thing which is easy to manage on HPC and a mess on miscellaneous user systems, and it's expensive to fix properly which brings us back to which opportunities are of highest commercial value. The positive side to this is that the foundational layers - the driver in the linux kernel and the llvm toolchain - are both developed primarily upstream. Building either from source is therefore likely to give you binaries that work. If they don't work, you can raise bugs against those projects directly. So it's quite DIY but at least you've got the pieces to work from. When cuda falls over, you've got no hope.