It makes sense in that context.
In EU you could have done it but because of US risks they killed it anyway.
That's not legal but who's gonna stop them.
Also, Wine does the same since forever for DOS binaries. Or NetBSD with compat_* libreries for tons of Unixlike OSes.
Just like it is not legal to do copyright infringement indifferent to how much you own the hardware you do it on.
AFAIK cublas and other first-party libraries are hand-optimized by nVidia for different generations of their hardware, with dynamic dispatch in runtime for optimal performance. Pretty sure none of these versions would run optimally on AMD GPUs because ideally AMD GPUs run 64 threads / wavefront, nVidia GPUs run 32 threads / wavefront.
It is legal for me to make a copy of any copyright protected media using hardware that I own. It is not legal for me to share this copy with others.
Sony Computer Entertainment v. Connectix Corp.
https://scholar.google.com/scholar_case?case=716676913673727...
> The object code of a program may be copyrighted as expression, 17 U.S.C. § 102(a), but it also contains ideas and performs functions that are not entitled to copyright protection. See 17 U.S.C. § 102(b).
> Object code cannot, however, be read by humans.
> The unprotected ideas and functions of the code therefore are frequently undiscoverable in the absence of investigation and translation that may require copying the copyrighted material.
> We conclude that, under the facts of this case and our precedent, Connectix's intermediate copying and use of Sony's copyrighted BIOS was a fair use for the purpose of gaining access to the unprotected elements of Sony's software.
> HIP is very thin and has little or no performance impact over coding directly in CUDA mode.
> The HIPIFY tools automatically convert source from CUDA to HIP.
That said, what _is_ AMD's platform? OpenCL? Vulkan compute? If they don't have an alternative, then the strategy doesn't make sense.
That is a very good question that apparently AMD has no good answer for. I have lost track of the amount of half baked implementations for GPGPU that AMD has attempted and then left to rot. Even if they told me they had the answer now, and they are going to put all their focus on that, I would not trust them to deliver on it. Their best bet is to create implementations for popular libraries like torch that actually stand a chance to work as a drop in replacement.
They heard that it was successful for Google?
A possible solution (that doesn’t involve being better than Nvidia at the things they are good at, which seems to be impossible) is to create frameworks that spit out CUDA or, whatever, OpenCL. Nobody actually wants to use the languages, right? Everybody loves CuBLAS and CuDNN, not CUDA, make GPUOpenBLAS. Maybe they could get Intel to come along with them.
Nobody cares about "users" in this case, it's bespoke applications running on bespoke infrastructure at scale.
"Production grade" feels pretty ambiguous. It either works or it doesn't for any particular developer's use case.