Hacker News Reader

Comment by jcranmer | Hacker News Reader

Disclosure: I work at Intel.

At one of the internal Q&As, there was a question as to why we didn't just implement CUDA. One of the reasons given was that the lawyers looked at the license of CUDA and decided that Intel could not legally implement CUDA for Intel's GPU devices. I don't know the details, but quite frankly, it wouldn't surprise me if Nvidia didn't somehow put a poison pill in there to prevent Intel or AMD from implementing it for their own GPUs (note that AMD also doesn't provide an implementation of CUDA for its own GPUs).

Instead, the strategy Intel pursued was to develop a migration tool from CUDA to Sycl: https://software.intel.com/content/www/us/en/develop/tools/o...

View on HN

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

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.

I am guessing that Nvidia only copied what Intel is doing with x86. Why don't Intel free the x86? A little bit of competition would be good for everyone, otherwise ARM will take over the market, so Intel has nothing to lose from doing that.

Why not collaborate with AMD for once an improve HIP? If AMD and Intel stay divided all hope is lost and nvidia will stay the main target

Because HIP/ROCm is awful.

Instead of targeting an IR, it directly targets a given GPU's ISA, so that your existing binary will not run on future hardware. That's a total no-go for basically every non-HPC use case.

Intel is much better off building a sound technical foundation from scratch.

You better make Zluda work well on AMD gpus then otherwise it will be irrelevant

And it doesn't even work on most consumer AMD graphic cards^^

Reply on news.ycombinator.com