Yes it is a legal issue. AMD cannot implement CUDA.
However, they have gone around that by creating HIP which is a CUDA adjacent language that runs on AMD and also translates to CUDA for Nvidia GPUs. There is also the HIPify tool to automatically convert existing sources from CUDA to HIP.
https://docs.amd.com/bundle/HIP-Programming-Guide-v5.3/page/...
x86 is protected by patents and only a few companies can use them, that’s why you don’t see random companies making x86 CPUs like they can with ARM (which also needs licensing but it’s much easier to get)
The first x86-64 processor has been released more than 20 years ago, so any patents on that base architecture (which includes SSE2) have already expired.
Good luck enforcing those software parents though in the current environment. My sense is that hardware companies put more faith in the enforceability of patent claims to something like CUDA than software companies with experience with litigating patent claims to APIs would. Post Oracle v. Google, something like CUDA is vulnerable to being knocked off.
And FWIW, that seems to be a reasonable result given the overall market structure at the moment. Having all eggs in the Nvidia basket is great for Nvidia shareholders, but not for customers and probably not even for the health of the surrounding industry.
genuine question, why don't these protections apply to emulators? How could emulators get away with emulating x86 but chip manufacturers cannot use x86 for their chips without a license?
Probably fair use, which is a subjective thing but one Intel must be confident enough they would lose. Or just lack of incentive, there is no money for Intel to gain if they win.
HIPify is such a half baked effort, in everything from installation to benchmark to marketing. It doesn't look like they are trying to support this method at all.
No, they ruled that APIs are copyrightable, but that Google's re-implementation was fair use. Based on the reasoning of the decision one would expect that in most cases independently reimplementing an API would generally be fair use. However, from a practical point of view, if you are defending yourself in a copyright lawsuit, fair use decisions happen much later in the process and are more subjective.
Furthermore, CUDA is a language (dialect of C/C++) not an API, so that precedent may not have much weight.
In the end, google reimplemented Java, and the supreme court ruled on a very narrow piece of the reimplementation. I think it came down to a former sun/oracle employee at google actually copy pasting code from the original java code base.
I'm reasonably sure they could reimplement CUDA from a copyright / trademark perspective. It's possible that they could be blocked with patents though.
> think it came down to a former sun/oracle employee at google actually copy pasting code from the original java code base.
IIRC, the verbatim copying of rangeCheck didn't make it to SCOTUS. They really did instead rule on the copyrightability of the "structure, sequence, and organization" of the Java API as a whole.
Because they ran their numbers and realized they have more to lose by going against Valve than... amicably find a compromise.
A more aggressive approach was tried during the Xbox 360 era with the Games For Windows Live framework and by removing their games from the Steam store. It ended up catastrophically bad and they had to backtrack on both decisions.
The irony of Proton de facto killing any chance for native linux ports of windows games isn't lost to them, either.
MS has been building lots of goodwill with gamers by bringing games to PC and subverting expectations by not being opposed to using game pass on Steam Deck. Suing Valve or trying to shut down Proton/DXVK would instantly burn all that.
Because these lawsuits are costly, a PR nightmare, loosing them is a serious possibility and going around fighting your competition with lawsuits can put you into a bad place with government agencies.
Playing games on linux is not a threat to microsoft. The money they loose on that is miniscule.
However, they have gone around that by creating HIP which is a CUDA adjacent language that runs on AMD and also translates to CUDA for Nvidia GPUs. There is also the HIPify tool to automatically convert existing sources from CUDA to HIP. https://docs.amd.com/bundle/HIP-Programming-Guide-v5.3/page/...