4 ms·

ROCm support can be kind of a joke, but Blender demonstrates its best side: it works on all consumer GPUs Vega and newer (no Polaris unfortunately), and on Wind

ROCm support can be kind of a joke, but Blender demonstrates its best side: it works on all consumer GPUs Vega and newer (no Polaris unfortunately), and on Windows. That said, the build instructions for Blender say that you can't compile the GPU program on Windows. (I am not sure how this works exactly with JIT vs AOT compilation.) AMD itself isn't working on SYCL to my knowledge, but you may be interested in hipSYCL which can compile SYCL code to HIP or CUDA. CUDA/HIP does have the advantage of a massive library of existing code and knowledge, and pre-existing libraries (e.g. cuPRIM, cuBLAS, etc) which you do not have on SYCL. I also believe AMD has AOMP for OpenMP offload. I do agree that AMD and Intel would be best off working together on GPU compute, so that they can say "look, our approach works on ALL vendors, not just us". However if Intel supports HIP on oneAPI, and maybe hipSYCL gets some sort of official support, we will be there already with both of their solutions.

sorenjan 4y ago
The last time I looked into it Blender's ROCm support seemed like a special case with support from AMD. I don't know if that's what it is, every time I try to get a handle on AMD's compute offering I get dizzy. There's so many different projects, Github repositories, sketchy hardware and OS support that changes with different driver versions (Close to Metal, Brook+, Stream Computing, AMD APP SDK, HSA, ROCm, HIP, AOMP, ). It seems very hacked together by a small team that can get defunded anytime, and it's not exactly confidence inspiring or ergonomic. As far as I can tell, HIP is still not generally available on Windows [0] or consumer gaming cards [1]. Not for developers, not for end users. That means hipSYCL can't be used by AMD users on Windows, and I don't see much value for Intel to support it either. I don't think HIP is going to take any significant share of the market, why use AMD's platform when they so clearly have demonstrated that they don't really care about compute for more than a decade now? I wish GPU compute could get to a maturity level where you could use any framework you wanted, compile it to SPIR-V, and then run it on any GPU on any OS. Let's say I write some image processing code, or ML inference, or audio processing, that I want to run on consumer's GPUs. What options are there today? Nvidia makes it easy, AMD makes it hard. [0] https://github.com/ROCm-Developer-Tools/HIP/blob/develop/INSTALL.md https://github.com/ROCm-Developer-Tools/HIP/blob/develop/INS... [1] https://github.com/ROCm-Developer-Tools/HIP/blob/develop/docs/markdown/hip_faq.md#what-hardware-does-hip-support https://github.com/ROCm-Developer-Tools/HIP/blob/develop/doc...
- ColonelPhantom 4y ago
  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".

sorenjan 4y ago

The last time I looked into it Blender's ROCm support seemed like a special case with support from AMD. I don't know if that's what it is, every time I try to get a handle on AMD's compute offering I get dizzy. There's so many different projects, Github repositories, sketchy hardware and OS support that changes with different driver versions (Close to Metal, Brook+, Stream Computing, AMD APP SDK, HSA, ROCm, HIP, AOMP, ). It seems very hacked together by a small team that can get defunded anytime, and it's not exactly confidence inspiring or ergonomic. As far as I can tell, HIP is still not generally available on Windows [0] or consumer gaming cards [1]. Not for developers, not for end users. That means hipSYCL can't be used by AMD users on Windows, and I don't see much value for Intel to support it either. I don't think HIP is going to take any significant share of the market, why use AMD's platform when they so clearly have demonstrated that they don't really care about compute for more than a decade now? I wish GPU compute could get to a maturity level where you could use any framework you wanted, compile it to SPIR-V, and then run it on any GPU on any OS. Let's say I write some image processing code, or ML inference, or audio processing, that I want to run on consumer's GPUs. What options are there today? Nvidia makes it easy, AMD makes it hard. [0] https://github.com/ROCm-Developer-Tools/HIP/blob/develop/INSTALL.md https://github.com/ROCm-Developer-Tools/HIP/blob/develop/INS... [1] https://github.com/ROCm-Developer-Tools/HIP/blob/develop/docs/markdown/hip_faq.md#what-hardware-does-hip-support https://github.com/ROCm-Developer-Tools/HIP/blob/develop/doc...

ColonelPhantom 4y ago
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".