4 ms·

> Ooooh, is that why the consumer cards don't do compute? No, not really. Sure, the consumer cards are based on a less suitable architecture, so they won't be

> Ooooh, is that why the consumer cards don't do compute? No, not really. Sure, the consumer cards are based on a less suitable architecture, so they won't be as good, but it's not like it's not a general purpose GPU architecture anymore. The real problem is that ROCm has made the very weird technical decision of shipping GPU machine code, rather than bytecode. Nvidia has their own bytecode NVPTX, and Intel just uses SPIR-V for oneAPI. This means that ROCm support for a GPU architecture requires shipping binaries of all the libraries (such as rocBLAS, rocDNN, rocsparse, rocFFT) for all architectures. As the cherry on top, on paper one GPU family consists of different architectures! The RX 6700 XT identifies as a different 'architecture' (gfx1031) than the RX 6800 XT (gfx1030). These are 'close enough' that you can tell ROCm to use gfx1030 binaries on gfx1031 and it'll usually just work, but still. I feel like this is a large part of the reason AMD is so bad about supporting older GPUs in ROCm. It'd cost a bit of effort, sure, but I feel like the enormous packages you'd get are a bigger issue. (This is another factor that kills hobbyist ROCm, because anyone with a Pascal+ GPU can do CUDA, but ROCm support is usually limited to newer and higher end cards.)

slavik81 3y ago
> As the cherry on top, on paper one GPU family consists of different architectures! The RX 6700 XT identifies as a different 'architecture' (gfx1031) than the RX 6800 XT (gfx1030). These are 'close enough' that you can tell ROCm to use gfx1030 binaries on gfx1031 and it'll usually just work, but still. As far as I can tell, the gfx1030 and gfx1031 ISAs are identical in all but name. LLVM treats them exactly the same and all tests for the ROCm math libraries will pass when you run gfx1030 code on gfx1031 GPUs using the override. The Debian package for HIP has a patch so that if the user has a gfx1031 GPU and there are no gfx1031 code objects available, it will fall back to using gfx1030 code objects instead. When I proposed that patch upstream, it was rejected in favour of adding a new ISA that explicitly supports all the GPUs in a family. That solution is more complex and is taking longer to implement, but will more thoroughly solve that problem (as the solution Debian is using only works well when there's one ISA in the family that is a subset of all the others).
JonChesterfield 3y ago
There was a ship-bytecode idea branded HSAIL, associated with opencl finalisers in some way. I'm not sure what killed that - would speculate that the compiler backend was annoyingly slow to run as a JIT. It's somewhat conceptually popular under the spirv branding now. Some of the ROCm libraries are partially written in assembly. Hopefully they all have C reference implementations that can be compiled for the other architectures. My guess is that the AMD strategy of only shipping libraries for some cards + open source means ROCm-ish as built by Linux distros, who are likely to build the libs for all the architectures and not just the special few, can be expected to drive people away from the official releases.

slavik81 3y ago

> As the cherry on top, on paper one GPU family consists of different architectures! The RX 6700 XT identifies as a different 'architecture' (gfx1031) than the RX 6800 XT (gfx1030). These are 'close enough' that you can tell ROCm to use gfx1030 binaries on gfx1031 and it'll usually just work, but still. As far as I can tell, the gfx1030 and gfx1031 ISAs are identical in all but name. LLVM treats them exactly the same and all tests for the ROCm math libraries will pass when you run gfx1030 code on gfx1031 GPUs using the override. The Debian package for HIP has a patch so that if the user has a gfx1031 GPU and there are no gfx1031 code objects available, it will fall back to using gfx1030 code objects instead. When I proposed that patch upstream, it was rejected in favour of adding a new ISA that explicitly supports all the GPUs in a family. That solution is more complex and is taking longer to implement, but will more thoroughly solve that problem (as the solution Debian is using only works well when there's one ISA in the family that is a subset of all the others).

JonChesterfield 3y ago

There was a ship-bytecode idea branded HSAIL, associated with opencl finalisers in some way. I'm not sure what killed that - would speculate that the compiler backend was annoyingly slow to run as a JIT. It's somewhat conceptually popular under the spirv branding now. Some of the ROCm libraries are partially written in assembly. Hopefully they all have C reference implementations that can be compiled for the other architectures. My guess is that the AMD strategy of only shipping libraries for some cards + open source means ROCm-ish as built by Linux distros, who are likely to build the libs for all the architectures and not just the special few, can be expected to drive people away from the official releases.