HIP: Convert CUDA to Portable C++ Code | Hacker News Reader

HIP: Convert CUDA to Portable C++ Code

github.com

134 pointsfla14 comments

It's a poorly-chosen title but a very cool project: it's not a source-to-source translator, you as a programmer are writing C++ instead of CUDA, and it compiles down to either CUDA or ROCm depending on whether you've got an NVIDIA or AMD GPU.

Very cool!

They claim to have a tool to do the CUDA to C++ conversion

* The "hipify" tool automatically converts source from CUDA to HIP. https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/tre...

That makes sense. I was going to pick up GPU programming, and I don't wanna learn CUDA just to use this tool.

Any guides on getting started with running ROCm?

My first question was "what about OpenCL", and they seem to address it here: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blo...

Indeed, "The HIP API is less verbose than OpenCL and is familiar to CUDA developers."

I have only looked at both approaches rather than developed for them but I am currently planning some GPU development and OpenCL seems like horrid mess to start with.

The frustrating thing with OpenCL is it gets mentioned constantly in these discussions as a "less proprietary" alternative to CUDA but it gives every impression of being one of those multivendor kitchen-sink concoctions - it's got a thousand flags to accommodate 100 flags/vendor and get improvements at a snail's pace to accommodate those vendors as well. Which isn't to say that it's something that can't developed for, just that it's intended for teams assigned to develop for a given chip and produce something essentially proprietary for chip (given are those "nice" customization flags) and so it's useless for the individual, independent developer. Thus OpenCL seems ultimately more proprietary than CUDA, which we can see is now convertable to other code because clearly not that different to start with.

Anyway, HIP looks far, far better OpenCL - something that allows the developer to just write C++ and then target whatever. With luck, all vendor will be forced to support this.

That's a good point, although I'd argue that anything is less proprietary than something that literally runs only on a single vendor's hardware.

Also, I feel that proprietary shouldn't be used as a synonym to targeted at specific hardware, because being truly independent of the hardware might just be too much to ask for.

But it's interesting to consider why HIP doesn't support compiling to OpenCL. They don't seem to address this in the FAQs, but I think the reason might be that in addition to all the other problems, OpenCL is terrible as an intermediate language for compiling C++ to OpenCL. If it wasn't, then I don't know a good reason for why something like HIP wouldn't support it out of the box. I mean, compiling C++ to C basically requires a full-blown C++ compiler, which is a huge investment of resources, so I really wonder how the decision was made to base OpenCL on C99. Because of all this, I'm not sure how to understand HIP in relation to the rest of the ecosystem.

> But it's interesting to consider why HIP doesn't support compiling to OpenCL.

It's not HIP that will support compiling _to_ OpenCL, but rather the compiler toolchain will have an OpenCL compiler that will compile down to ISA [1], promised to be released for the ROCm stack in the coming weeks [2].

[1] https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... [2] https://github.com/RadeonOpenCompute/ROCm/issues/30

> so I really wonder how the decision was made to base OpenCL on C99.

The OpenGL group has always been hostile to anything other than C, it was required to see them being beaten by CUDA, C++AMP, DX, Metal to finally acknowledge C++ in OpenCL and Vulkan API definitions.

> Thus OpenCL seems ultimately more proprietary than CUDA,

Could not be further from the truth there! OpenCL is an open standard, can be used to program GPU, CPU and even FPGA. It is definitively NOT proprietary in any sense! To target both AMD and NVidia GPU, you do not need any vendor specific flag at all. Yes, OpenCL, is like OpenGL pretty verbose and explicit. It can be a bit tedious but once you've factored this verbosity in a framework of some kind, it becomes pretty easy to use.

HIP seems interesting, but I am unwilling to invest on it yet. What will happen if for whatever reason AMD abandon it in 6 months? No such worries with OpenCL.

OpenCL just like its graphics cousin, is full of extensions leading to multiple code paths, if one wants to take advantage of GPU features.

Also AFAIK there isn't any vendor supporting OpenCL 2.1, which means we are forced to use C or languages with compilers that are able to target C. Including the whole dance of loading, compiling and linking at runtime.

If AMD decides to go HIP only, and given that no mobile OS cares about OpenCL support, then those worries apply to it as well.

https://github.com/hughperkins/cuda-on-cl

What about Fortran support?

Meanwhile, still nobody cares about compute shaders.

For actual compute apps, no. But for doing image post processing in games, most AAA games use compute shaders. This might even include (deferred) lighting.

This might change with Vulkan since it doesn't need a windowing system (like OpenGL) to do compute or offscreen rendering. So far it hasn't been viable to do OpenGL compute shaders because you need to set up a window (or a pbuffer) and you need to have X11 running (or interact with window system on Win32/OSX).

Reply on news.ycombinator.com