No, you don't _need_ to use CUDA for GPU programming, you can use OpenCL or Vulkan or probably even PHP instead.
I do, however, _want_ to use the best programming language for the task at hand. If that task is GPU programming, CUDA is the best language I know for that, much better than SyCL, OpenCL, Vulkan / OpenGL + shaders, etc.
If these other technologies would be better, I would use them instead.
Not that this matters because your argument is flawed.
The claim that CUDA is not worth using because it lacks portability, only holds, if there is hardware worth using that's not supported by CUDA.
The only GPUs worth buying for compute are from nvidia and support CUDA, so your claim isn't true.
The only thing you achieve today by not using CUDA is paying a huge price in development quality for portability that you can't use.
The startup cemetery is filled with companies that made this trade-off and picked OpenCL just in case they wanted to use non-nvidia hardware. They were all killed by the velocity of their competitors that were using CUDA to deliver better products that payed the bills.
The only people for which it might make sense to avoid CUDA are "non-professionals" (hobbyist, etc.). If you only want to use OpenCL to "learn OpenCL", then OpenCL is the right choice. But if you want to make money, then CUDA was the right choice 15 years ago and still is the right choice today.
If that makes you angry, direct your anger properly. It isn't NVIDIA's fault that CUDA is really good. It is however, AMD's, Intel's, Apple's, Qualcomm, ARM's... fault that everything else _sucks hard_. Being angry at nvidia for delivering good products is just stupid. Its the other companies fault that they can't seem to be able to get their sh* together when it comes to GPU computing.
That sounds like koolaid marketing to me. AMD GCN was more compute oriented than Nvidia for years and only lately AMD increased focus on gaming with RDNA.
That's a fact: check HPL, MLPerf, Spec, etc. results. MLPerf is the perfect example, were your results are only accepted if they can be verified by others. Where is AMD in there? (nowhere, their products suck for compute).
> AMD GCN was more compute oriented than Nvidia for years
No, the only thing AMD GCN was good for is as a very expensive stove.
AMD GCN had a lot of compute, on paper, and higher numbers than nvidia GPUs of the time. Unfortunately, AMD GCN's memory subsystem sucked, and it was impossible to deliver data fast enough to actually be able to use the compute.
So nvidia's hardware essentially destroyed GCN for any useful practical application.
IIRC, the only application for which GCN's got some use was bitcoin mining, which avoided hitting GCN's issues because it just requires doing a ton of useless work on a tiny amount of memory. Perfect for GCN right? Nope, nvidia's hardware was still better, but sold out, and GCN wasn't horrible at this, so it got some use.
AMD actually fired the architect of GCN over this. Yet this still perfectly summarizes AMD's GPGPU strategy of the last 15 years: higher numbers on paper, that cannot be achieved in practice, and lower that the numbers that nvidia's hardware achieves in practice.
NVidia cannot be blamed for their incompetency.
Why didn't AMD do this as well? I thought AMD was strong on supporting open source.
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.
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 ?
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.
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.
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.
Today it should be easier to target compute queues with something like Vulkan though, which is a generic GPU API, not limited to graphics.
Vulkan Compute so far hasn't gotten anywhere.
I don't call lock-in shenanigans a fair advantage. And supporting lock-in is a slippery slope.
There aren't any.