Hacker News Reader

Comment by dagmx | Hacker News Reader

Khronos is where APIs go to die, and new ideas stagnate.

OpenCL 2 turned into an inaccessible mess, in contradiction of where Apple had originally targeted it to go. Even Nvidia turned their noses up at it.

Khronos denied the early shared development of what turned into Metal when Mantle was shown to be super promising, and then released Vulkan years later as a response that has had incredibly slow adoption due to the same over complexity that OpenCL died from.

I like that you specifically blame Apple though and ignore that Nvidia were one of the reasons that the Khronos partnership for both the things I mentioned didn’t work out. NVIDIA chose to not support OpenCL2. And they’re the ones who pushed hard on AZDO OpenGL when AMD and Apple were pushing for Mantle/Metal instead

View on HN

Nvidia already had a proprietary compute architecture, they were the only business in the position that could say no. Even then, they never stopped third-parties from implementing OpenCL2 in software. They simply didn't implement it themselves. In any case, if your CUDA-killer relies on Nvidia's cooperation then your plan is hopeless from the start.

If Apple is capable of subsuming Khronos' place, now is the time to do it. If not, Nvidia's still in pole position and Apple doesn't have the hardware to overtake them anytime soon.

> when AMD and Apple were pushing for Mantle/Metal instead

You wanna explain the 999 IQ reason why AMD doesn't beg for Metal IP like they did in 2014? It's pretty cut-and-dried, I'm surprised to see you highlight it as an argument.

I would rather blame Intel and AMD for never delivering anything that could beat CUDA, and Google for completly ignoring OpenCL on mobile rather pushing Renderscript.

Agree with most of the other stuff.

Yeah fair points. Both Intel and AMD tripped over each other multiple times inexplicably trying to chase CUDA. Which is sad because ATI was very early to GPU Compute.

Google flubbed the usual route of “someone’s passion project that will die when they’re no longer rewarded for maintaining it”

> and then released Vulkan years later as a response that has had incredibly slow adoption due to the same over complexity that OpenCL died from.

I agree with everything else you said, but as someone who has used both OpenCL and Vulkan, the complexity is not comparable in the slightest. Even for pure compute applications, Vulkan is radically more annoying to use than OpenCL, though of course both are much worse than CUDA (or even Metal). OpenCL is somewhat annoying, but usable if you're okay with a basic C API, whereas Vulkan feels like an insufferable waste of time.

Oh for sure. Sorry, I didn’t mean they were the same level of complexity as each other. Just that they’re significantly more complex than their respective alternatives.

Reply on news.ycombinator.com