AMD announces CUDA support
anandtech.comNo, it didn't. The title is misleading, AMD is announcing tools to make it easier to port from CUDA. Not the same as supporting CUDA, which is owned by nVidia only. Unless nVidia open-sources CUDA, AMD cannot do anything for it.
The article said the same thing:
> Through HIP AMD will bridge the gap between HCC and CUDA by giving developers a CUDA-like syntax – the various HIP API commands – allowing developers to program for AMD GPUs in a CUDA-like fashion. Meanwhile HIP will also including a toolset (the HIPify Tools) that further simplifies porting by automatically converting CUDA code to HIP code. And finally, once code is HIP – be it natively written that way or converted – it can then be compiled to either NVIDIA or AMD GPUs through NVCC (using a HIP header file to add HIP support) or HCC respectively.
> To be clear here, HIP is not a means for AMD GPUs to run compiled CUDA programs. CUDA is and remains an NVIDIA technology. But HIP is the means for source-to-source translation, so that developers will have a far easier time targeting AMD GPUs.
What's even worse is that it may not be legal either:
> Now there are some unknowns here, including whether AMD can keep HIP up to date with CUDA feature additions, but more importantly there’s a question of just what NVIDIA’s reaction will be. CUDA is NVIDIA’s, through and through, and it does make one wonder whether NVIDIA would try to sue AMD for implementing the CUDA API without NVIDIA’s permission, particularly in light of the latest developments in the Oracle vs. Google case on the Java API. AMD for their part has had their legal team look at the issue extensively and doesn’t believe they’re at risk – pointing in part to Google’s own efforts to bring CUDA support to LLVM with GPUCC – though I suspect AMD’s efforts are a bit more inflammatory given the direct competition. Ultimately it’s a matter that will be handled by AMD and NVIDIA only if it comes to it, but it’s something that does need to be pointed out.
Why the heck would any developers use HIP with this legal issue up in the air?
> Why the heck would any developers use HIP with this legal issue up in the air?
Probably because if just implementing an API really turns out to be a disallowed by law - and I'm not familiar enough with the Google/Oracle case in particular or the law in general to know how well it generalizes to such a conclusion - then most of the stuff I rely on goes poof anyway.
The way the Oracle/Google case got resolved was that the Federal Circuit made a ruling that almost everyone agreed was wrong with respect to the copyright issues but that there was little danger of any other circuit ruling that way on future cases that didn't have a patent aspect to get them in front of the Federal Circuit. Part of the Supreme Court's reasoning for not taking up the issue probably was that the Federal Circuit hadn't and couldn't create any binding precedent in the matter (as they were supposed to be following the local circuit's law on the non-patent aspects of the case).
I think the main issue is that most research is done in C++ and Fortran.
Both are not supported by OpenCL, which is one of the reasons many researchers go CUDA instead.
Khronos finally got out of their C only APIs mentality with the upcoming revision of OpenCL, but apparently AMD might have felt it is already too late to make developers use something SPIR based, with most vendors already targeting PTX.
Why would it be too late for something SPIR-based? Vulkan and OpenCL 2.1 will be compiling to SPIR-V.
Existing code bases and knowledge with the current tools.
You will need C++ and Fortran compilers able to target SPIR with the same set of language features, debugging tools and libraries that CUDA has available today.