Slashdot Mirror
NVIDIA Releases Source To CUDA Compiler
An anonymous reader writes "NVIDIA has announced they have 'open-sourced' their new CUDA compiler so that their GPGPU platform can be brought to new architectures. NVIDIA's CUDA compiler is based upon LLVM. At the moment though they seem to be restricting the source code's access to 'qualified' individuals.'
The official press release implies wider access to the source will happen later. It so happens that a few days ago AMD opened their OpenCL backend and added initial support to the Free Software r600 driver.
Based on what we know about the high-end AMD 7000 series, that it will forgo VLIW for separate threads, CUDA might actually work very well on that architecture. As long as the right 'qualified' individuals work on it.
(T>t && O(n)--) == sqrt(666)
If they would open source video drivers too NVIDIA would be clear card of choice in *nix systems.
Does this mean eventually running CUDA applications on AMD GPUs?
Despite the phrase "open-source", there seems to be a distinct lack of information about whether this is a "source is now available for inspection" type release, or actually under an open-source license, and if so, which one.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Title is correct. From TFA, the summary appears wrong. It seems they are not open sourcing anything. To quote TFA
On December 13th, NVIDIA announced that it will open up the CUDA platform by releasing source code for the CUDA Compiler.
They will let you look at the code, and they might let you send patches back to them. Nowhere I can find did NVIDIA promise anything along the lines of an open license, or even any license at all. This is more like a Microsoft shared-source deal, where you can look, but no rights or privileges are transferred to you.
That said, it would still be cool to see.
Stikypad [sic] has "given away" all of his "money" to a "qualified individual."
https://www.eff.org/https-everywhere
Discrete graphics is going away, they seem to be leaning increasingly towards the HPC market but that is tiny compared to the consumer graphics market that their company was built on. I just don't see it. Anyone?
Does this mean that AMD/ATI and nVidia are finally recognizing that the only people really losing out in their cold war are their users? I'm traditionally an AMD/ATI customer but have been leaning towards getting an nVidia card for the CUDA support in Adobe's Creative Suite, but if this means that at some point in the future the Radeon HD 7000 series will support CUDA and will potentially accelerate CS, then I'll stick with it...
The sharpest blade is no match for the sharpest mind.
This is the kind of disagreement in which neither side can ever hope to convince the other. Let's just say that you are free to do almost anything you want under a BSD license. That's an objective fact. You are not compelled to contribute back any improvements you may make in a work. Which one contributes more to global "freedom" is much too broad and slippery a concept to ever resolve unanimously.
IMO, open sourcing their GPU libraries would be a much bigger deal than only open sourcing the compiler. I would like to see CUBLAS, CUFFT, CUSPARSE, CURAND, etc all get opened up to the community.
The pain is not in compiling GPU code; rather, the pain is in writing good GPU code. The major difference between NVIDIA and AMD (and the major edge NVIDIA has over AMD) is not as much the compiler as it is the libraries.
Of course, I'm biased, because I work at AccelerEyes and we do GPU consulting with our freely available, but not open source, ArrayFire GPU library, which has both CUDA and OpenCL versions.
OK, then how do you explain the rather large numbers of companies that give back to BSD projects? This anti-BSD FUD that the Linux and GPL camp seem to need to spread got old many,many years ago.
Without a permissive license the internet would have been greatly delayed as MS and the others would have had to develop their own TCP/IP stack from scratch.
OpenCL is a much better path, because it can execute code on a CPU as well as a GPU.
So can CUDA, according to a graphic in one of the featured articles: "NVIDIA C or C++, PGI Fortran, or new language support, through LLVM-based CUDA compiler, to NVIDIA GPUs, x86 CPUs, and new processor support."
They are making some of the best mobile/low-power solutions with the Tegra [nvidia.com] family of chip-sets.
That and nForce.
it's still going to take some time before the integrated solutions (Intel IGP and AMD Fusion) are good enough to replace discrete graphics for gamers
SWF games, such as those seen on Facebook, are targeted at PCs with Intel GMA (Graphics My Ass) IGPs. So to people for whom "gaming" means FarmVille and "upgrade" means buying a new PC, integrated graphics have replaced discrete.
Xbox 360 and Wii have "integrated graphics" by AMD in the sense that the GPU is on the northbridge. The 360's graphics are also "integrated" in the sense that all 512 MB of its RAM can be used as VRAM. I'm not very familiar with the PS3 architecture other than that half its 512 MB of RAM is exclusive to the NVIDIA RSX GPU, so I don't know what other functions the RSX does in addition to GPU operations. But at least for people who game on an Xbox 360 or Wii and do not game on the PC, integrated graphics have replaced discrete.
I believe that is consonant with my comment. Not everyone only does what they are compelled to do. I have BSD licensed some of my own code.
I think if there was a way to run the kernel in the CUDA cores would be awesome. I have a GTX GeForce 560 Ti - 384 cores. That would be awesome even if to use 1/2 of those in the kernel. Even if we used the GeForce 8800 with 112 cores. Wow...this could be awesome to use those for something productive. If you know of a linux that will run in the CUDA cores I would be happy to know about it.
A big part of the trade secrets business in competing GPU's is how things are done in the details - how the problems are phrased or broken up between the CPU and GPU, and exactly what algos are used in each. No one patents this stuff, it's all trade-secret. So no one wants to open source their drives, where all this information lives. Stinks, but there it is.
Why guess when you can know? Measure!
BSD is the perfect license to apply to a layer of software that helps people talking to the hardware you sell.
If somebody wants to "steal" it, and make something great without sharing upstream, well, great for you, more people will buy your hardware.
Rethinking email
I despise Nvidia for not opening up their drivers, but I still use them on Linux and Windows. Why? Because their drivers don't crash my box half as often as the ATi drivers do if I use them the way I want to, or ATi simply doesn't do what I want. In the end, I much prefer open source, but I'll use whatever gets me the best results for my application. My computers are first and foremost tools, not political advocacy devices.
Blaming the lack of success for ATi on Linux desktops on the fact that they went open source simply doesn't hold. They were behind before they went open source and even tho they improved greatly, they are still significantly behind Nvidia when it comes to Linux drivers.
I was promised a flying car. Where is my flying car?
That depends on your definition of freedom. I prefer freedom in the sense that I know the code will always remain free and available. As a developer and user I want my code to be always available, I also want contributors to never close what I made open in the first place. I prefer freedom in the sense of Free software, GPL and strong copy-left. AKA "Liberty or Death".
BSD brings uncertainty when it comes to having contributors closing the source code and not contributing back.
GPL has its place, I agree. But unfortunately the usage of it is often 'wrong', or malicious IMHO.
You probably wouldn't gain anything. Passing data between your CPU and GPU has a high latency penalty. OpenVPN processes small amounts of data. You would need to probably buffer a few hundred KB before it would become worth it.
A GPU would be great for any large amounts of data, like a block device, but small packetized datastreams work best with super low latency instruction level acceleration.
My guess anyway.
long time.
I'm going to print it out and put it on the shelf next to:
* "Buggy whip industry still growing with no end in sight"
* "Refrigeration is no threat to the ice delivery business"
* "Travel agents expect little competition from internet sales"