Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nvidia Opens CUDA Platform, Releases Compiler Source Code

developer.nvidia.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#21

Post by melonakos »

dxbydt wrote: post #13
melonakos wrote: post #9

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.…

> 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/... ). In finance, we are actively looking at CUDA…

Over the last 5 years, I've seen a ton of hot air blown about wrt to auto-GPU code generation. The latest hot air is about how magical directives make everything run fast.

Truth is, compilers and code generators are crappy.

If you really want to get good performance, you either have to write your own low-level GPU kernels, or use a library of functions that have already been written at a low-level.

All other hot air, while interesting, has yet to be proven at scale on more than a few limited use cases.

Another disclaimer: I work on this, http://accelereyes.com/arrayfire

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#22

Post by keeperofdakeys »

ajross wrote: post #8
adrianscott wrote: post #5

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

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).

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.

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#23

Post by rbabich »

dxbydt wrote: post #13
melonakos wrote: post #9

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.…

> 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/... ). In finance, we are actively looking at CUDA…

As an author of that paper, I can tell you that the code generator was rather simple and mainly used to perform loop unrolling, avoid explicit indexing, and replicate bits of code that couldn't quite be encapsulated in inline functions. It's possible to go further, but this sort of metaprogramming doesn't really eliminate the need to write in CUDA C.

For what it's worth, we long ago abandoned scala in favor of python for the code generator, just to make it more accessible to others interested in working on the project (generally particle physicists by training): http://lattice.github.com/quda/

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#24

Post by DiabloD3 »

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.

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#25

Post by [deleted] »

DiabloD3 wrote: post #24

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]

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#26

Post by srean »

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/

[2] http://sourceforge.net/projects/sisal/

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#27

Post by wmf »

andrewcooke wrote: post #19
dxbydt wrote: post #13

Earlier quoted context omitted.

> 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/... ). In finance, we are actively looking at CUDA…

are you confusing syntax and semantics? there's a hurdle that you need to cross with writing cuda code because it's C-like and easy to make "stupid mistakes". a code generator would help you there. but the harder part is getting the algorithm correct (and optimal, for a range of sizes of data). a generator is not so much use there (except for polymorphism, where templating helps). or am i missing something? how do yo…

Code generators like ATLAS let you generate a thousand variations of the code and pick the fastest one.

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#28

Post by mappu »

keeperofdakeys wrote: post #22
ajross wrote: post #8

Earlier quoted context omitted.

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).

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.

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)

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#29

Post by sharpneli »

melonakos wrote: post #21
dxbydt wrote: post #13

Earlier quoted context omitted.

> 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/... ). In finance, we are actively looking at CUDA…

Over the last 5 years, I've seen a ton of hot air blown about wrt to auto-GPU code generation. The latest hot air is about how magical directives make everything run fast. Truth is, compilers and code generators are crappy. If you really want to get good performance, you either have to write your own low-level GPU kernels, or use a library of functions that have already been written at a low-level. All other hot air,…

There are 2 parts in writing good GPU code, parallelizing the algorithm and writing the kernels. Automatization of one part will not save time on other.

Based on practical experience the compilers are pretty good nowadays. The fine details of the kernel do not matter that much. The performance issues tend to float around usage of local memory, bank conflicts and how much one kernel instance does work, which require hand tuning and in these cases the compilers are underperforming. Thankfully the poor kernels are 'just' constant factor in the general time complexity of the algorithm.

On higher level the most important thing is to describe the actual algorithm. If the algorithm is described as serial one there is no automated way (and most likely will not ever be general way) of parallelizing it, except running it to check data dependencies after which you already have the result, and the dependencies can change based on inputs so result of one run cannot be generalized.

This could probably be proved by similar method as with halting. The program calls the autoparallelizer and if the parallelizer says there is no data dependency between 2 parts it will make them dependent, if it says there is it will make them independent.

Thus let it be clear: There is no way whatsoever to take the hard parts away (thinking in parallel). Nothing will take bunch of serial code in and spit parallel programs out.

Re: Nvidia Opens CUDA Platform, Releases Compiler Source Code

#30

Post by keeperofdakeys »

mappu wrote: post #28
keeperofdakeys wrote: post #22

Earlier quoted context omitted.

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.

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)

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.
Post reply on HN