What about OpenCL and CUDA C++ alternatives?

(modular.com)

19 points | by eatonphil 4 days ago

1 comments

  • 20k 1 hour ago
    I've been programming in OpenCL for 10+ years. This article is clearly AI generated, and its also completely wrong

    OpenCL did not fragment into a mess of vendor specific extensions. I don't know where that even comes from, the extensions in the 1.1/1.2 days were very minimal. The story goes like this:

    1. OpenCL 1.2 turned up. This was the first really viable version of OpenCL, although 1.1 was usable. It started to gain a fair bit of traction

    2. As OpenCL increasingly started to eat at Nvidia's cuda dominance, Nvidia deliberately killed OpenCL support by neglecting it. There literally did 0 technical development on it for years, with long running critical bugs remaining unfixed

    3. At some point, OpenCL started to gain prominence in machine vision stuff in the embedded world, especially for cars and that space. Nvidia's poor OpenCL support became a liability, and so they heavily invested in OpenCL, fixed all the old bugs, and implemented OpenCL 3.0 support

    4. Apple dropped OpenCL support because their anti competitive market strategy is vendor lock in, so a cross platform cross vendor API is bad for them. There's some kind of long running legal clusterfuck going on between Apple, and Khronos, the details of which are not public

    5. AMD's OpenCL support was absolutely great. A+_best in class, would recommend. It had a fair bit of buggyness/jankyness, but it was an order of magnitude better than Nvidia's support back when Nvidia was deliberately hamstringing it. Then they started developing ROCm

    6. Around this time, Vulkan was standardised. Khronos had been considering merging OpenCL into vulkan to force vendors to support it properly, but this was killed. Instead, we got the absolutely insane OpenCL-specific SPIRV format that nobody has ever used for anything

    7. With the advent of ROCm, AMD abandoned OpenCL. They swapped over their good OpenCL compiler, to a new compiler that is much shitter and still has way worse performance. OpenCL is now badly implemented on top of ROCm, but some of it is so buggy its clear that nobody has ever used it. They refuse to implement 3.0 support, even though Nvidia supports it

    8. The tables have turned: AMDs GPU compute support sucks donkeyballs, and Nvidia is lightyears ahead of them

    OpenCL is not a story of fragmentation. Its a story of how vendors deliberately independently set out to kill it, along with AMD's incompetence, and Khronos making several boneheaded decisions during its standardisation that lead to it being cut off at the knees

    Despite this, OpenCL 1.2 is still by far the best cross platform cross vendor GPU Compute API, because it is the only one that exists. Vulkan still doesn't support everything you need. Its a nightmare all around

    • Reubend 1 hour ago
      Thanks so much for explaining this. I was just about to comment "Isn't Vulkan the main OpenCL and CUDA alternative these days?" could you share a bit more on what Vulkan is missing relative to the other two?
    • gspr 1 hour ago
      This is a fantastic overview. I learned a lot, thanks!

      As someone whose only experience with GPU programming (except very high-level stuff via Torch) has been OpenCL, I gotta say I found it really pleasant! I've always wondered why it didn't take off, and hate the current situation.

      I looked with hope at Vulkan, but am saddened by what you write about it. Could you elaborate on what the state of Vulkan Compute is, and where it might go from here?