That’s fair, for me it never worked with any of the hardware or software I wanted it to and I’m not enough of a GPU expert to really fix that myself, so for me and many others I found with similar problems it definitely has yet to become a workable solution, but I was probably a bit harsh if I came across like I thought it didn’t work at all, I’ve seen it demoed and I know it works, but for such a restrictive set of hardware and software that Ive never seen it in use myself outside of demonstrations.

As for Vulkan, I tend to think of CUDA at the driver level given how closely coupled it is to Nvidia’s hardware. So I wasn’t really thinking about broader cross compatible APIs like Vulkan which tend to get implemented on top of the drivers providing low level access like CUDA gives… but with the exception of Apple (because we know they will never change their mind) I’m hoping the broader industry gets behind Vulkan compute shaders enough we finally get something that delivers on the promises made when the OpenCL effort began. I want clean understandable abstractions over the top of all the different SIMD and MIMD capabilities we have these days it doesn’t have to magically compile my code down to FPGA hardware but how about actually being able to get the best matrix multiplication performance out of both my CPU or GPU or both if I have a CPU with the right kind of integrated GPU that they can efficiently enough share memory and both work together without slowing each other down when working on an embarrassingly parallel matrix multiplication task. Is this really too much to ask of software in an an era that gives us near magical JIT performance in multiple languages, and manages to build cross compile/transpilation tools that can convert entire assembly code bases into JavaScript and all the other nice things we have as software developers… it never felt like too much to me but the fate of OpenCL appears to disagree.