7 ms·

Nvidia Opens CUDA Platform, Releases Compiler Source Code

302 points by Garbage 15y ago

danieldk 15y ago
Unfortunately, it does not say what license will be used, which is probably relevant if they want to create an ecosystem around the compiler.
- exDM69 15y ago
  I agree that the exact licensing terms are somewhat relevant if you intend to depend on this software. However, it's worth noting that the compiler in question is LLVM based. So you can construct your own compiler frontend that generates LLVM IR code that can be compiled for CUDA by their backend. It's very likely that there are some CUDA-specific LLVM intrinsics, so the frontend will not be entirely independent of CUDA compiler licensing terms but at least now you have a somewhat open interchange format to use between your frontend and the CUDA backend.
justincormack 15y ago
we just need documentation to understand what the generated code does then, as AFAIK the output is code for undocumented hardware.
- sparky 15y ago
  There's a good chance the LLVM backend will emit PTX, not machine code. PTX is well documented [1]. Under such a system, the generated PTX would be JITed at runtime by the driver. Note that LLVM already has a (very experimental and not complete) PTX backend [2]. [1] http://developer.download.nvidia.com/compute/cuda/3_0/toolkit/docs/ptx_isa_2.0.pdf http://developer.download.nvidia.com/compute/cuda/3_0/toolki... [2] http://llvm.org/releases/3.0/docs/ReleaseNotes.html#whatsnew http://llvm.org/releases/3.0/docs/ReleaseNotes.html#whatsnew
  - paxswill 15y ago
    I'm pretty sure this is the case by playing with the OpenCL side of CUDA. If the '--version' flag is passed to the OpenCL compiler (at least the one with CUDA 3.0), info from an LLVM build from a year ago is dumped. The '-cl-nv-verbose' flag is also documented to pass '--verbose' to the ptxas assembler.
- oneofthose 15y ago
  It is undocumented but you can get a fairly decent idea of what is going on if you have a good understanding of such architectures in general and from the sparse documentation they provide, if you run microbenchmarks and use tools such as decuda (https://github.com/laanwj/decuda/wiki https://github.com/laanwj/decuda/wiki). Also people working with those devices are often scientists that are eager to share what they found out (if only to say "You're doing it wrong!"). See for example Vasily Volkov's work here http://www.cs.berkeley.edu/~volkov/ http://www.cs.berkeley.edu/~volkov/
- pbsd 15y ago
  It's slightly better documented these days, ever since cuobjdump is bundled with the compiler tools. It allows SASS output, which is supposed to be the native machine code of the Fermis.
adrianscott 15y ago
This sounds very exciting! I guess it's not totally related, but I hope VLC Player will get better Nvidia hardware acceleration soon...!
- ajross 15y ago
  It's pretty much not related at all. VLC is a player UI client, it doesn't have codecs of its own. You should be wishing for better GPU acceleration in libavcodec if anything (but even that isn't implemented with CUDA).
  - keeperofdakeys 15y ago
    VLC is more then a UI, they have to implement the decoders in libavcodec, and they do a lot of work to package things underneath. FFmpeg also supports VDPAU (the nvidia, linux video acceleration api), but it would still be some work for VLC to implement it.
    - mappu 15y ago
      VLC does use VA-API on linux, though. I guess the rationale is that people with high-end AMD and nVidia GPUs are likely to have plenty of CPU horsepower, and acceleration is mostly needed for people with those intel IGPs that VA-API supports. (EDIT: the real reason VA-API is used over VDPAU or XvBA is probably pragmatic and related to driver stability)
      - keeperofdakeys 15y ago
        After having a look at VA-API vs VDPAU, I must say VDPAU is much nicer. VDPAU allows you to define times when frames will be shown, so vsync is handled fully in hardware; more than one transparent sub-picture can also be shown at one time.
melonakos 15y ago
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.
- melonakos 15y ago
  Also, OpenCL is not going away, even if someone figured out how to get CUDA code to run well on ATI GPUs. OpenCL is gaining a lot of traction by mobile GPU vendors too (e.g. ARM Mali, Imagination PowerVR, Qualcomm Adreno, etc)
  - T_S_ 15y ago
    I think you meant OpenCL is not going away, and I agree.
    - melonakos 15y ago
      right :) i fixed it.
- dxbydt 15y ago
  > the pain is in writing good GPU code A viable alternative is to not write the GPU code yourself. Write a code generator in Scala that spits out GPU code in C. For details see Claudio Rebbi's work, which uses Scala as a higher level code genarator for CUDA to solve the Dirac-Wilson equation on the lattice( http://wwwold.jlab.org/conferences/lattice2008/talks/poster/claudio_rebbi.pdf http://wwwold.jlab.org/conferences/lattice2008/talks/poster/... ). In finance, we are actively looking at CUDA for derivative pricing problems in risk analytics. None of us wants to actually write GPU code in C, and we do have considerable amount of risk analytics work being done in Scala, so a code generator might actually be the way to go.
binarycrusader 15y ago
Key wording to observe here -- they said they'd release the source code, not that it would be under an open source license. They're "opening the platform". We'll see what they actually do.
japaget 15y ago
The title of this post is slightly misleading. The actual article does not state that Nvidia has released the source code yet, but only that they are planning to do so in the near future. A signup form is provided so that you can be sent an e-mail when Nvidia actually does release the source code.
varelse 15y ago
This answers the #1 objection to using CUDA instead of OpenCL: vendor lock. What it doesn't answer is who's going to write the compilers and if they will ever happen. But it does prove NVIDIA is still a player in the many-core game and that there are still a few more rounds to go before there's a winner.
DiabloD3 15y ago
Until Mesa/Gallium implements a CUDA stack, I see no point in caring what Nvidia does or doesn't do with their source code. And, most likely, CUDA will never be done by Mesa/Gallium unless quite a few people porting legacy CUDA get together and make it happen. OpenCL is a multi-vendor supported actual standard, even Nvidia is part of the Khronos OpenCL group, slightly implying that even Nvidia has admitted defeat.
- deleted 15y ago
  [deleted]
srean 15y ago
There have been few comments about using specialized code generators, for example Theano[1] written in Python and as mentioned in a comment quda. I do not have the background to understand them well, but I find them very interesting. One question that I have is whether anyone has looked at adapting or using the IF2 backend of the Sisal programming language [2] for these. I ask because some of the optimization that Theano does reminds me of things that IF2 is supposed to be doing too. Sisal was written with the old school vector machines and supercomputers in mind but has a backend that depends only on the availability of pthreads. I suspect that it might be possible to add support for SSE and its ilk. [1] http://deeplearning.net/software/theano/ http://deeplearning.net/software/theano/ [2] http://sourceforge.net/projects/sisal/ http://sourceforge.net/projects/sisal/

302 points by Garbage 15y ago

Unfortunately, it does not say what license will be used, which is probably relevant if they want to create an ecosystem around the compiler.

exDM69 15y ago
I agree that the exact licensing terms are somewhat relevant if you intend to depend on this software. However, it's worth noting that the compiler in question is LLVM based. So you can construct your own compiler frontend that generates LLVM IR code that can be compiled for CUDA by their backend. It's very likely that there are some CUDA-specific LLVM intrinsics, so the frontend will not be entirely independent of CUDA compiler licensing terms but at least now you have a somewhat open interchange format to use between your frontend and the CUDA backend.

justincormack 15y ago

we just need documentation to understand what the generated code does then, as AFAIK the output is code for undocumented hardware.

sparky 15y ago
There's a good chance the LLVM backend will emit PTX, not machine code. PTX is well documented [1]. Under such a system, the generated PTX would be JITed at runtime by the driver. Note that LLVM already has a (very experimental and not complete) PTX backend [2]. [1] http://developer.download.nvidia.com/compute/cuda/3_0/toolkit/docs/ptx_isa_2.0.pdf http://developer.download.nvidia.com/compute/cuda/3_0/toolki... [2] http://llvm.org/releases/3.0/docs/ReleaseNotes.html#whatsnew http://llvm.org/releases/3.0/docs/ReleaseNotes.html#whatsnew
- paxswill 15y ago
  I'm pretty sure this is the case by playing with the OpenCL side of CUDA. If the '--version' flag is passed to the OpenCL compiler (at least the one with CUDA 3.0), info from an LLVM build from a year ago is dumped. The '-cl-nv-verbose' flag is also documented to pass '--verbose' to the ptxas assembler.
oneofthose 15y ago
It is undocumented but you can get a fairly decent idea of what is going on if you have a good understanding of such architectures in general and from the sparse documentation they provide, if you run microbenchmarks and use tools such as decuda (https://github.com/laanwj/decuda/wiki https://github.com/laanwj/decuda/wiki). Also people working with those devices are often scientists that are eager to share what they found out (if only to say "You're doing it wrong!"). See for example Vasily Volkov's work here http://www.cs.berkeley.edu/~volkov/ http://www.cs.berkeley.edu/~volkov/
pbsd 15y ago
It's slightly better documented these days, ever since cuobjdump is bundled with the compiler tools. It allows SASS output, which is supposed to be the native machine code of the Fermis.

adrianscott 15y ago

This sounds very exciting! I guess it's not totally related, but I hope VLC Player will get better Nvidia hardware acceleration soon...!

ajross 15y ago
It's pretty much not related at all. VLC is a player UI client, it doesn't have codecs of its own. You should be wishing for better GPU acceleration in libavcodec if anything (but even that isn't implemented with CUDA).
- keeperofdakeys 15y ago
  VLC is more then a UI, they have to implement the decoders in libavcodec, and they do a lot of work to package things underneath. FFmpeg also supports VDPAU (the nvidia, linux video acceleration api), but it would still be some work for VLC to implement it.
  - mappu 15y ago
    VLC does use VA-API on linux, though. I guess the rationale is that people with high-end AMD and nVidia GPUs are likely to have plenty of CPU horsepower, and acceleration is mostly needed for people with those intel IGPs that VA-API supports. (EDIT: the real reason VA-API is used over VDPAU or XvBA is probably pragmatic and related to driver stability)
    - keeperofdakeys 15y ago
      After having a look at VA-API vs VDPAU, I must say VDPAU is much nicer. VDPAU allows you to define times when frames will be shown, so vsync is handled fully in hardware; more than one transparent sub-picture can also be shown at one time.

melonakos 15y ago

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.

melonakos 15y ago
Also, OpenCL is not going away, even if someone figured out how to get CUDA code to run well on ATI GPUs. OpenCL is gaining a lot of traction by mobile GPU vendors too (e.g. ARM Mali, Imagination PowerVR, Qualcomm Adreno, etc)
- T_S_ 15y ago
  I think you meant OpenCL is not going away, and I agree.
  - melonakos 15y ago
    right :) i fixed it.
dxbydt 15y ago
> the pain is in writing good GPU code A viable alternative is to not write the GPU code yourself. Write a code generator in Scala that spits out GPU code in C. For details see Claudio Rebbi's work, which uses Scala as a higher level code genarator for CUDA to solve the Dirac-Wilson equation on the lattice( http://wwwold.jlab.org/conferences/lattice2008/talks/poster/claudio_rebbi.pdf http://wwwold.jlab.org/conferences/lattice2008/talks/poster/... ). In finance, we are actively looking at CUDA for derivative pricing problems in risk analytics. None of us wants to actually write GPU code in C, and we do have considerable amount of risk analytics work being done in Scala, so a code generator might actually be the way to go.

binarycrusader 15y ago

Key wording to observe here -- they said they'd release the source code, not that it would be under an open source license. They're "opening the platform". We'll see what they actually do.

japaget 15y ago

The title of this post is slightly misleading. The actual article does not state that Nvidia has released the source code yet, but only that they are planning to do so in the near future. A signup form is provided so that you can be sent an e-mail when Nvidia actually does release the source code.

varelse 15y ago

This answers the #1 objection to using CUDA instead of OpenCL: vendor lock. What it doesn't answer is who's going to write the compilers and if they will ever happen. But it does prove NVIDIA is still a player in the many-core game and that there are still a few more rounds to go before there's a winner.

DiabloD3 15y ago

Until Mesa/Gallium implements a CUDA stack, I see no point in caring what Nvidia does or doesn't do with their source code. And, most likely, CUDA will never be done by Mesa/Gallium unless quite a few people porting legacy CUDA get together and make it happen. OpenCL is a multi-vendor supported actual standard, even Nvidia is part of the Khronos OpenCL group, slightly implying that even Nvidia has admitted defeat.

deleted 15y ago
[deleted]

srean 15y ago

There have been few comments about using specialized code generators, for example Theano[1] written in Python and as mentioned in a comment quda. I do not have the background to understand them well, but I find them very interesting. One question that I have is whether anyone has looked at adapting or using the IF2 backend of the Sisal programming language [2] for these. I ask because some of the optimization that Theano does reminds me of things that IF2 is supposed to be doing too. Sisal was written with the old school vector machines and supercomputers in mind but has a backend that depends only on the availability of pthreads. I suspect that it might be possible to add support for SSE and its ilk. [1] http://deeplearning.net/software/theano/ http://deeplearning.net/software/theano/ [2] http://sourceforge.net/projects/sisal/ http://sourceforge.net/projects/sisal/