3 ms·

I don't think any GPU vendors really back OpenCL anymore. I honestly doubt it will see much if any growth in the future. Of course, the most used stack is curr

I don't think any GPU vendors really back OpenCL anymore. I honestly doubt it will see much if any growth in the future. Of course, the most used stack is currently CUDA, which is proprietary and only works on Nvidia. AMD made its own version called HIP, which translates quite directly to CUDA, but also runs on AMD cards via ROCm. Intel has its own stack called oneAPI, which I think is based on SYCL, a Khronos standard (just like OpenCL/OpenGL/Vulkan/etc). I believe SYCL programs can also be ran on AMD and NVIDIA using third-party compilers/translation tools such as hipSYCL, and I think SYCL can also be compiled to OpenCL. I recently also heard about efforts to support running HIP programs on SYCL, so hopefully soon GPU compute will be less vendor-bound, with CUDA translating relatively easily to HIP, and HIP and SYCL also not offering compatibility problems either way.

rrss 4y ago
another option that IMO is worth mentioning in this list is writing code using parallelism features in standard languages (e.g. C++20 algorithms with std::execution::par) and having a compiler compile it to run on whichever target.
bjourne 4y ago
That's unfortunate because OpenCL seems like a great idea. SYCL is very similar to OpenCL, except it is based on C++17 instead of C99. Not a great advantage I think because for HPC you want to get as close to the metal as possible.
- ColonelPhantom 4y ago
  The main advantage of approaches like CUDA and SYCL is that host code and device code are written in the same language. That makes it easier to e.g. deal with custom structs. Also, I don't buy that C99 is that much closer to the metal than C++17. From what I've seen, a lot of code still uses C-style anyway (e.g. C arrays). C++ just adds some nice stuff like namespaces. (I think a lot of the standard library would not work GPU-side anyway, at least with CUDA/HIP.)
  - bjourne 4y ago
    True, though for me, control over placement of memory buffers and low-level scheduling is way more important than C++ lambdas and getting to write kernels in the host language. Those benefits are certainly not great enough to throw the whole eco-system out and start over. :/
    - ColonelPhantom 4y ago
      There's honestly barely an OpenCL ecosystem to speak of. Even Blender abandoned it. Also, at least with CUDA and HIP, you need to manually malloc GPU memory, and explicitly launch GPU kernels (using <<<>>> syntax for CUDA or optionally hipLaunchKernel for HIP). Ecosystem is the main problem of anything not CUDA or sort-of compatible like HIP. A ton production GPGPU code uses CUDA.
sorenjan 4y ago
It should be noted that AMD's ROCm doesn't work on most consumer gaming GPUs, unlike CUDA, and doesn't work on Windows. So it's not a good choice if you're writing software for end users where you can't control their hardware and software, unlike data centers. IMHO, AMD has made themselves irrelevant in GPU compute, and should work hard together with Intel to support SYCL on all GPUs and all popular OSs to enable developers and end users to use GPU for compute without being stuck with proprietary solutions.
- ColonelPhantom 4y ago
  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...

rrss 4y ago

another option that IMO is worth mentioning in this list is writing code using parallelism features in standard languages (e.g. C++20 algorithms with std::execution::par) and having a compiler compile it to run on whichever target.

bjourne 4y ago

That's unfortunate because OpenCL seems like a great idea. SYCL is very similar to OpenCL, except it is based on C++17 instead of C99. Not a great advantage I think because for HPC you want to get as close to the metal as possible.

ColonelPhantom 4y ago
The main advantage of approaches like CUDA and SYCL is that host code and device code are written in the same language. That makes it easier to e.g. deal with custom structs. Also, I don't buy that C99 is that much closer to the metal than C++17. From what I've seen, a lot of code still uses C-style anyway (e.g. C arrays). C++ just adds some nice stuff like namespaces. (I think a lot of the standard library would not work GPU-side anyway, at least with CUDA/HIP.)
- bjourne 4y ago
  True, though for me, control over placement of memory buffers and low-level scheduling is way more important than C++ lambdas and getting to write kernels in the host language. Those benefits are certainly not great enough to throw the whole eco-system out and start over. :/
  - ColonelPhantom 4y ago
    There's honestly barely an OpenCL ecosystem to speak of. Even Blender abandoned it. Also, at least with CUDA and HIP, you need to manually malloc GPU memory, and explicitly launch GPU kernels (using <<<>>> syntax for CUDA or optionally hipLaunchKernel for HIP). Ecosystem is the main problem of anything not CUDA or sort-of compatible like HIP. A ton production GPGPU code uses CUDA.

sorenjan 4y ago

It should be noted that AMD's ROCm doesn't work on most consumer gaming GPUs, unlike CUDA, and doesn't work on Windows. So it's not a good choice if you're writing software for end users where you can't control their hardware and software, unlike data centers. IMHO, AMD has made themselves irrelevant in GPU compute, and should work hard together with Intel to support SYCL on all GPUs and all popular OSs to enable developers and end users to use GPU for compute without being stuck with proprietary solutions.

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