Wow, this is great news. This attitude is the exact reason Nvidia is doing so well at GPGPU (General Purpose GPU, using a graphics card for things other than graphics). Look over at hgpu.org, you'll see 77% of research papers on there are based on Nvidia hardware (like the GTX 480), and most papers based on CUDA.
Those who are interested in this stuff should checkout previous discussions on HN. There had been quite a few when the plan to open source the compiler was announced about 4 months ago. In fact I remember a thread about pathscale planning to reverse engineer the runtime and compiler, this is also referenced in the current post.
I would also recommend keeping an eye on the manticore project, they have had some success compiling nested parallel constructs into GPU instruction that is very competitive with hand optimized code. Though this seems such an obvious thing to do, it is deceptively hard, very hard.
The title is not 100% accurate. CUDA has come to mean the tool chain and ecosystem for GPGPU programming. Part of the system is the particular dialect of C++ in which a programmer can mix and match CPU and GPU code. It also includes the compiler that translates the GPU part to object code (the ISA is called PTX [1] which is one level removed from the actual GPU's ISA). What NVIDIA has open-sourced is the part that translates LLVM IR to PTX. The greatest benefit of this will be for people who are developing alternate programming models/DSLs for programming GPUs. They can translate their DSL to LLVM IR, which they probably are already doing, and then generate PTX using the open-source compiler.
So between this and gdev (https://github.com/shinpei0208/gdev), is it now (or soon to be) possible to write CUDA in Linux with both an open toolchain and without the nVidia binary blob for video cards? Or am I misunderstanding what's going on here?
I'm trying to figure that out too. But my guess is no: this compiler spits out a blob that needs to be fed to the proprietary NVIDIA driver. It exposes (but doesn't really "document") the functionality of the compute engine (and maybe the texture units?). It doesn't touch the DMA engine for getting the data on and off the card, nor the interface to the hardware schedule to make it run.
No. It does not generate GPU binaries. It generates "PTX", which is a pseudo-assembler format. You then feed the PTX to Nvidia driver to generate the actual binary. AFAIK the actual ISA and binary formats are not openly (officially) documented.
wow, a company that refuses to release hardware documentation sans NDA has open sourced something. let's give them a gold star!
by forcing OS devs to sign NDAs it has actively slowed down the open source community. releasing open source code to make further use of their own products is talking out of both sides of their mouth.
I don't see how nVidia is being hypocritical here at all or "talking out of both sides of their mouth"; it's their right to contribute what work they want to.
Meanwhile, nVidia continues to have the best 3D Display Drivers on Linux, Windows, OS X, Solaris, and FreeBSD.
In contrast, the open source drivers even after having years of access to complete specifications to the 3D/2D-portions of hardware AMD provides has barely gotten OpenGL 3.x working and performance is barely half the commercial drivers in many cases.
Yes, they omit parts that are covered by macrovision copy-protection and the like, but those are not necessary for full 3D support. That is why I qualified my earlier statement.
The real reason is as you pointed out, writing drivers is hard and the skillset is scarce.
I just wanted to point out that most people believe the myth that full specifications == instant, great open source drivers.
12 comments
[ 2.5 ms ] story [ 37.9 ms ] threadI would also recommend keeping an eye on the manticore project, they have had some success compiling nested parallel constructs into GPU instruction that is very competitive with hand optimized code. Though this seems such an obvious thing to do, it is deceptively hard, very hard.
Links:
http://news.ycombinator.com/item?id=3351967
http://news.ycombinator.com/item?id=1458922
https://plus.google.com/109384228201962198714/posts/LzQDmzTf...
[1] http://en.wikipedia.org/wiki/Parallel_Thread_Execution
by forcing OS devs to sign NDAs it has actively slowed down the open source community. releasing open source code to make further use of their own products is talking out of both sides of their mouth.
Meanwhile, nVidia continues to have the best 3D Display Drivers on Linux, Windows, OS X, Solaris, and FreeBSD.
In contrast, the open source drivers even after having years of access to complete specifications to the 3D/2D-portions of hardware AMD provides has barely gotten OpenGL 3.x working and performance is barely half the commercial drivers in many cases.
Also, writing drivers is hard and the open source ones were written from scratch. They're pretty good for (low) amount of effort put into it.
The real reason is as you pointed out, writing drivers is hard and the skillset is scarce.
I just wanted to point out that most people believe the myth that full specifications == instant, great open source drivers.