are there insurmountable technical constraints there, or could it be resuscitated?
The issues go away if you use a good OpenCL frontend. PyOpenCL for Python goes a long way towards this, and is not really any more awkward than the corresponding PyCUDA, and higher-level languages that generate OpenCL code, like Lift[0] or Futhark[1] (tooting my own horn here), remove the awkwardness completely.
[0]: http://www.lift-project.org/ [1]: https://futhark-lang.org
You're not wrong there. However with the advent of SPIR-V it is possible to write code in whatever language you please (with the caveat that at the moment you need an LLVM backend using https://github.com/thewilsonator/llvm-target-spirv or the Khronos repo I forked that off of. Then comes the issue of making the code generator friendly interface user friendly, which I have done for D so that you get the ease of use of CUDA.
OpenGL ES only took off thanks to gaming on the iPhone, and now is deprecated on Apple platforms.
Vulkan still lives in a C world, and the semi-official C++ bindings only exist thanks NVidia.
OpenCL waited too long to support C++, Fortran and providing an infrastructure for compiler writers to add GPU support to their own languages. And two years later the majority of drivers are not there yet.
Which Khronos finally adopted as SPIR, but the drivers aren't there yet.
Regarding the other Khronos APIs, a C API is like being stuck in a PDP-11 world.
Many mix the idea of C API with OS ABI, it only happens to be the same if the OS APIs are exposed as plain C.
There many cases where this isn't like it, e.g. mainframes, mobile OSes, and most userspace on OS X (Obj-C runtime) and Windows (.NET and COM).
Yes driver support is a bit lacking, although I hop that I can convince the OpenCL working group of the need to get a backend (such as https://github.com/thewilsonator/llvm-target-spirv) into mainline LLVM so that writing drivers becomes easier for vendors.
And segmenting the codebase is a MAJOR feature. With CUDA you are stuck on an old compiler until NVIDIA issues an update. How anyone can think this is a good idea...
"Designing (New) C++ Hardware”
https://www.youtube.com/watch?v=86seb-iZCnI
CUDA has had C++, Fortran support since the early days, with PTX for additional compiler backends added in version 1.4.
That was 2007, Khronos waited until 2015 to specific similar capabilities.
People still write regular shaders in languages that are much more C like.
People writing GPGPU code are few. Most of the DL GPU use is in Python through several layers, and in the end you are running hand-written SASS assembly sitting in an NVIDIA DLL or whatever.
I guess some people must think it's handy to have C++ support in GPU kernels, or they wouldn't have added the feature. But for it to drive technology, hard to believe.
The Metal, DirectX, PS3, PS4, Nintendo and several middleware engines are C++ like.
Also the fact that OpenCL lost to CUDA for being stuck in C for so long, shows what most GPU devs actually prefer.
Aw come on, you're sure it has nothing to do with the largest GPGPU vendor pushing CUDA very heavily and intentionally gutting their OpenCL tools? Or putting out a ton of very high performance libraries with no OpenCL equivalent? Putting out a shitton of marketing and tutorial videos for CUDA only?
Yeah, that surely was totally unrelated.
Also pushing a proprietary standard goes faster than a standardized one. No surprise there.
If AMD, Intel and embedded OEMs actually produced quality OpenCL drivers, debugger and IDE support and libraries that could match CUDA productivity, maybe devs would bother to use C with OpenCL.
Even Google decided to create their Renderscript dialect instead of supporting OpenCL on Android.
I am saying that if the other GPU vendors bothered to actually provide a competing technology stack, that was worth the pain of using plain C, maybe GPU devs would have bothered.