Hacker News Reader

Comment by eslaught | Hacker News Reader

AMD implemented HIP, which is nearly CUDA (if not identical). There is an implementation for Intel too though it is third-party:

https://github.com/cpc/hipcl

View on HN

The problem here seems to be that everyone kinda wants Nvidia's market capture. Intel didn't contribute to AMD's project - they started their own.

And they are all approaching it the wrong way, the typical hubris of a hardware company that thinks they can just have some interns make a software solution for their problem.

Here is how you beat the CUDA lock-in: consistently make better performing GPUs so not using them is a liability. Instead buying AMD you not only get a worse GPU but also the intern software solution, and that is just not compelling.

Or AMD could simply knock off the binary blobs. The DRM excuse has always been weak, because it is a tiny fraction of the total firmware blob - and it'd be easy to make it so that the legally hobbled hardware decoder simply errors out in cases where the end user chooses not to load the DRM blob. Boom, no more dependence on AMD interns. I've been following their commit logs pretty closely for a year now, and I frequently see some amazing accidental admissions about the left hand (software team) not knowing what the right hand (hardware team) is doing. During one very frustrating series of patches it was difficult resisting the impulse to say "Go get your dad."

It doesn't help if they don't offer the same GUI debugging capabilities, and polyglot support as CUDA does in its current form.

Not only that, everyone that has jumped into SYSCL is doing SYSCL + their own sugar on top, so what is the "portability" selling point actually?

Also they keep forgetting that CUDA is not only C++, rather a polyglot eco-system.

Reply on news.ycombinator.com