Wednesday, March 6th 2024

NVIDIA Cracks Down on CUDA Translation Layers, Changes Licensing Terms

NVIDIA's Compute Unified Device Architecture (CUDA) has long been the de facto standard programming interface for developing GPU-accelerated software. Over the years, NVIDIA has built an entire ecosystem around CUDA, cementing its position as the leading GPU computing and AI manufacturer. However, rivals AMD and Intel have been trying to make inroads with their own open API offerings—ROCm from AMD and oneAPI from Intel. The idea was that developers could more easily run existing CUDA code on non-NVIDIA GPUs by providing open access through translation layers. Developers had created projects like ZLUDA to translate CUDA to ROCm, and Intel's CUDA to SYCL aimed to do the same for oneAPI. However, with the release of CUDA 11.5, NVIDIA appears to have cracked down on these translation efforts by modifying its terms of use, according to developer Longhorn on X.

"You may not reverse engineer, decompile or disassemble any portion of the output generated using Software elements for the purpose of translating such output artifacts to target a non-NVIDIA platform," says the CUDA 11.5 terms of service document. The changes don't seem to be technical in nature but rather licensing restrictions. The impact remains to be seen, depending on how much code still requires translation versus running natively on each vendor's API. While CUDA gave NVIDIA a unique selling point, its supremacy has diminished as more libraries work across hardware. Still, the move could slow the adoption of AMD and Intel offerings by making it harder for developers to port existing CUDA applications. As GPU-accelerated computing grows in fields like AI, the battle for developer mindshare between NVIDIA, AMD, and Intel is heating up.
Source: HardwareLuxx
Add your own comment

35 Comments on NVIDIA Cracks Down on CUDA Translation Layers, Changes Licensing Terms

#26
AnotherReader
WirkoX86 emulation is allowed. Emulation of X86 ISA extensions that are still under patent protection is allowed if you're Microsoft or Apple. Emulation of Arm ISA, for example - I don't know but Arm ISA is a major product they make money on, by selling it to architectural licence holders. QEMU is inefficient enough and Arm doesn't see it as a threat.
Even Transmeta was allowed to release processors that ran x86 code. Wine is a better example, and while Microsoft hampered it, they never sued anyone. When you are exceeding peak Microsoft levels of asshattery, you have to stop and think if what you're doing is right in the long run.
Posted on Reply
#27
R-T-B
Robin SeinaSuch move is probably illegal anyway. There is even a precedent in US law, when IBM's hdds got reverse engineered in 196x.
Why reference such an ancient case when we have Oracle v Google and it decided that yes, these things are legal, at the level of the Supreme Court no less?

No I don't agree with it either but it seems to be law right now.
AnotherReaderEven Transmeta was allowed to release processors that ran x86 code. Wine is a better example, and while Microsoft hampered it, they never sued anyone. When you are exceeding peak Microsoft levels of asshattery, you have to stop and think if what you're doing is right in the long run.
All those are really in a legal grey area since Oracle v Google. Wine basically exists because Microsoft doesn't want the bad PR of suing it. Transmeta was made before the Oracle v Google case so they didn't know what hot water it was getting into.
Posted on Reply
#28
AnotherReader
R-T-BWhy reference such an ancient case when we have Oracle v Google and it decided that yes, these things are legal, at the level of the Supreme Court no less?

No I don't agree with it either but it seems to be law right now.


All those are really in a legal grey area since Oracle v Google. Wine basically exists because Microsoft doesn't want the bad PR of suing it. Transmeta was made before the Oracle v Google case so they didn't know what hot water it was getting into.
Didn't Oracle vs Google find in Google's favour, but sidestep the issue of copyrighting APIs?
Posted on Reply
#29
R-T-B
AnotherReaderDidn't Oracle vs Google find in Google's favour, but sidestep the issue of copyrighting APIs?
Reading the detailed wiki article, it seems you are right. They basically allow it in a very narrow "fair use" context.
Posted on Reply
#30
Minus Infinity
AnotherReaderDidn't Oracle vs Google find in Google's favour, but sidestep the issue of copyrighting APIs?
I'd like Nvidia to prove to the Supreme Court using CUDA on other hardware is not fair use. Google won the case 6-2 so Nvidia would have a hell of time getting them to overturn their own decision.

Nvidia can write what they want, but they have no legal standing. No one is reverse engineering their API.

Google vs Oracle
Posted on Reply
#31
trsttte
R-T-BThey basically allow it in a very narrow "fair use" context
Not really that narrow, the four pillars of fair use have been well described, there's loads of room for interpretation but clear guidelines exist for what can constitute fair use.
Minus InfinityI'd like Nvidia to prove to the Supreme Court using CUDA on other hardware is not fair use. Google won the case 6-2 so Nvidia would have a hell of time getting them to overturn their own decision.

Nvidia can write what they want, but they have no legal standing. No one is reverse engineering their API.

Google vs Oracle
A saving grace for google was how little of java api's they've used and how many different things they did with it. A cuda wrapper would need to cover almost everything and try to do as close to the same as cuda as possible so the case would lead to different discussions
Posted on Reply
#32
Wirko
CUDA, Wine, Java, x86 - we have mentioned several [legal] cases that have little in common between them to make any predictions on this latest one. The case of x86 is probably the most similar.

What exactly is Nvidia trying to protect here? Not the ISA - it remains secure by being obscure enough, as of now. Not the CUDA API - at least Tom's Hardware notes that "Recompiling existing CUDA programs remains perfectly legal. To simplify this, both AMD and Intel have tools to port CUDA programs to their ROCm and OpenAPI platforms, respectively."

So they are legally protecting their compiled binaries, or rather the IP contained within. The big precious bunch of optimisations and whatever else. And how much does this matter? Full compilation is necessary anyway if one wants the best performance, and we don't buy accelerators for mediocre performance, right?
Posted on Reply
#33
john_
Minus InfinityNvidia can write what they want, but they have no legal standing.
Do they care if they can have any legal standing?
For example. Let's say that I go to my neighbor and I say "Look, we are good neighbors but if you keep watering your garden at 10 pm I will call the police and sue you". Even if my neighbor knows that the police will do nothing and I have no legal base in what I say, he still might stop or consider stopping watering his garden at 10 pm just to avoid ending up with a hostile neighbor. And in my opinion, this is what Nvidia tries to do. Scare people.
Posted on Reply
#34
RUSerious
pavleWhy stupid? I remember well when/how it started - it was Cg or C for graphics on GeForce3 and much time and effort went into producing the tool CUDA is today, so no wonder nvidia defends it. AMD and intel surely didn't chip in for development... Make sense.
Yeah, started out with researchers using shader engines for more general compute. CUDA debut was 2007 and the GF 8800 series really started to get the ball rolling with better compute capabilities. I think it would be a case of irresponsible fiduciary execution if the company didn't protect their investors by maximizing profits. Nvidia could be sued for that. So, they are not really being mean, or even greedy - they are acting in the best interests of it's investors and their employees.
Posted on Reply
#35
Wirko
So I went looking up Wiktionary to maybe find zluda in Croatian/Serbian, and found this in Polish instead. That guy knew how to pick a name so closely related to AI.

Posted on Reply
Add your own comment
May 15th, 2024 16:15 EDT change timezone

New Forum Posts

Popular Reviews

Controversial News Posts