The nice part of HIP is that it's essentially CUDA. So it's very easy to migrate (and presumably also migrate back; though I believe HIP for NVIDIA is just a si

The nice part of HIP is that it's essentially CUDA. So it's very easy to migrate (and presumably also migrate back; though I believe HIP for NVIDIA is just a simple header that maps HIP constructs to the same CUDA construct using #define anyway). Also, my RX 580 is not officially supported, and doesn't work in Blender either (even when trying to compile it myself, as I got a compiler error related to LLVM limitations), but developing things myself seems to mostly just work so far. I also managed to port LeelaChessZero from the cuBLAS backend to hipBLAS without noteworthy problems (and gained a fair bit of speed over the OpenCL backend). (I still want to try and get it working with hipDNN, which I threw out at my first port attempt because hipify-clang got confused over various #IFDEFs but hipify-perl does not seem to have that issue). Installing also hasn't been too bad for me on Arch Linux, I just installed an AUR package that pulls in most of AMD's binary packages (opencl-amd-dev) and now I have working hipcc and all that in /opt/rocm/. I do agree that the situation could be far better, but if I can take a fairly simple CUDA app and port it in an afternoon to work on my consumer GPU, I don't think the situation is completely terrible either. Also, as for various stacks, Close to Metal is very long ago. I've honestly never heard of Brook+ or Stream Computing. As for the others, I think AMD APP, HSA, ROCm, HIP and AOMP are all sort of part of the same stack. For example, my OpenCL driver which I believe is part of the ROCm stack identifies as AMD-APP. HIP and AOMP are then both like compiler frontends for the ROCm compute stack. For the any-GPU any-OS SPIR-V wish, Vulkan or OpenCL are probably your best bet, although that won't meet "any framework".