GPUCC: An Open-Source GPGPU Compiler [video] | Hacker News Reader

GPUCC: An Open-Source GPGPU Compiler [video]

images.nvidia.com

33 pointssingularity200115 comments

It's just frustrating how everything GPU related is fragmented, mostly proprietary, overly complex and hard to use. Cuda? nvidia only, directX? windows only, Metal? iOS/OS X only, OpenGL? too high level, too much stuff, too complex.

If you don't specialize on utilizing graphic cards, then as a normal programmer you simply won't use them. I really hope that Vulkan and SPIR-V might tackle that problem.

Even when you specialize, you aren't privy to the same sort of functionality or information exposed to the inner circle of lead game developers, so you have to spend a lot more effort to gain the same insights.

This is an Open Source CUDA compiler (not clear from the title).

I guess at the moment, this targets Nvidia GPUs. I wonder how much effort it would be to target other vendors GPUs. Does someone has some insights on that? This could mean that we can finally use CUDA for all GPUs.

It solves a fundamentally different problem, AFAIK - it emits CUDA kernels which are then just handed to the driver's interface for copying and running CUDA kernels on the GPU, so if your GPU doesn't support it, they'd need to change the LLVM backend to emit something other than a CUDA kernel (OpenCL, I suppose?).

It compiles CUDA (a C++ like language) using LLVM down to host ISA (x86) and virtual low-level NV virtual assembly (SASS/PTX). Only translation from virtual assembly to model-specific GPU assembly is left to closed-source NV code.

For AMD porting you could possibly use http://llvm.org/docs/AMDGPUUsage.html

According to the video, they have an a runtime library (StreamExecutor) which abstracts over CUDA and OpenCL. That seems like the hard part to me. Switching out the LLVM backend for kernels ought to be relatively easy.

I wonder how much of this was motivated by Nervana System's successes building their own assembler for Neon [0], or if perhaps this work started before it.

In either case more openness for low level hardware optimizations is always welcome and beneficial to the community.

[0] https://github.com/NervanaSystems/nervanagpu

I was wondering the same.

Video player is bugged for me in Chrome (doesn't stop stuttering after you do a seek).

Direct video link: http://s3-2u.digitallyspeaking.com/assets/nvidia/events/sc15...

This is a great thing since OpenCL has been spiraling towards the abyss after its main proponent (Apple) abandoned it, and programers seemed to prefer the less buggy and less verbose CUDA anyway.

In history of computing there seems to be an advantage for technologies with a single "de facto" implementation that is a compatibility target.

Being a C only API, while CUDA always had C++ and Fortran support didn't help either.

And that Fortan is still the language of choice for HPC - And has the support for CUDA allready

The biggest problem with OpenCL is that Google banned it (in favour of its own crippled RenderScript).

Please do not use the titles of HN submissions to editorialize. (Submitted title was "Google breaks into Nvidia fortress (via OS compiler)".)

https://news.ycombinator.com/newsguidelines.html

Reply on news.ycombinator.com