
HIP: Convert CUDA to Portable C++ Code - fla
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP
======
haldean
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!

~~~
DeepYogurt
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...](https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/tree/master/hipify-clang)

------
conistonwater
My first question was "what about OpenCL", and they seem to address it here:
[https://github.com/GPUOpen-ProfessionalCompute-
Tools/HIP/blo...](https://github.com/GPUOpen-ProfessionalCompute-
Tools/HIP/blob/master/docs/markdown/hip_faq.md#how-does-hip-compare-with-
opencl)

~~~
joe_the_user
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.

~~~
conistonwater
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.

~~~
slizard
> 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...](https://www.phoronix.com/forums/forum/linux-graphics-x-org-
drivers/open-source-amd-linux/881414-amd-radeon-rx-480-on-
linux?p=882080#post882080) [2]
[https://github.com/RadeonOpenCompute/ROCm/issues/30](https://github.com/RadeonOpenCompute/ROCm/issues/30)

------
m_mueller
What about Fortran support?

------
aamederen
Meanwhile, still nobody cares about compute shaders.

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

