Hacker News Reader

Comment by hobofan | Hacker News Reader

Though this is a snapshot from ~2015, I don't think anything has significantly changed since then:

I developed a (more or less popular, though not in wide use) ML framework[0] back then. NVIDIA pretty quickly contacted us and offered to send a Titan X (top-of-the-line back then) our way.

We also tried to make the framework work with OpenCL, but were severely limited in doing so. Mostly because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset. They started doing that once they had a decent lead in the market over AMD. With that OpenCL was no longer vendor agnostic, but rather AMD-only, and you would always need to fully support both backends to support both vendors.

Yes, Nvidia may produce the best GPUs right now and have great market and mindshare, but there is nothing "honest and deserved" about how they got there.

[0]: https://github.com/autumnai/leaf

View on HN

> because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset

So I suppose you still used OpenCL for AMD and Intel hardware because that worked well there? That is, OpenCL only worked poorly on nvidia hardware?

If that's the case, I wonder what's your take on OpenCL 3.0 reverting all OpenCL > 1.2 features, such that OpenCL 3 is essentially OpenCL 1.2. The reason given by Khronos is that _nobody_ was implementing these features anyways. Yet your story sounds like AMD had great support for OpenCL newer features, and only nvidia's support was poor, kind of contradicting Khronos themselves.

Maybe you meant that nvidia has poor support for OpenCL 1 ?

Not sure if I can offer a good take, as I don't 100% remember. We didn't have much resources to tackle OpenCL, as it was already hard enough to compete against the other frameworks on the CUDA side alone, so that's where our focus was until our company shut down. IIRC we had all the basics working with OpenCL 1.2 (with an Intel CPU and Titan X as test devices) and were looking into transitioning towards 2.0, as the abstractions used there were much closer to those in CUDA. I remember particularly the memory management in 1.2 to be a pain and difficulties around async RAM<->VRAM copies and subsequent async kernel execution. The latter in particular accounted for the biggest performance differences when profiling the same tasks on the Nvidia GPU.

I'm not really informed about what happened with OpenCL 3.0, but I would count any 2.x features as essential when trying to compete with modern CUDA. I don't think the support for OpenCL _the standard_ was bad, but there wasn't really any comparable tooling for OpenCL, and a set of good cuBLAS, cuDNN, etc. alternatives was missing. If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake.

> If OpenCL 3 is really reverting back to 1.2, that sounds like a big mistake.

See: https://www.anandtech.com/show/15746/opencl-30-announced-hit...

This was also extensively discussed here in HNs. You might be able to find that thread, was really interesting.

The fact that OpenCL is stuck on a C dialect, while CUDA is a polyglot runtime already puts OpenCL out of the game for me.

In fact it was thanks to this that Khronos finally woke up, but it was too late, and almost no one cares to target SPIR, while SYSCL just decided to go backend agnostic with the whole 1.2 => 3.0 rebranding.

As for the rest, rules of the game.

Nvidia has been doing this anti-competitive junk for years. There is nothing honest and deserved about crooked practices.

Today it should be easier to target compute queues with something like Vulkan though, which is a generic GPU API, not limited to graphics.

Another example of Khronos being stuck with C mindset and poor tooling.

Vulkan Compute so far hasn't gotten anywhere.

Reply on news.ycombinator.com