3 ms·

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 h

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 https://github.com/cpc/hipcl

lumost 6y ago
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.
- stefan_ 6y ago
  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.
  - tal8d 6y ago
    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."
  - pjmlp 6y ago
    It doesn't help if they don't offer the same GUI debugging capabilities, and polyglot support as CUDA does in its current form.
- pjmlp 6y ago
  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.

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 https://github.com/cpc/hipcl

lumost 6y ago

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.

stefan_ 6y ago
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.
- tal8d 6y ago
  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."
- pjmlp 6y ago
  It doesn't help if they don't offer the same GUI debugging capabilities, and polyglot support as CUDA does in its current form.
pjmlp 6y ago
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.