5 ms·

HIP: Convert CUDA to Portable C++ Code

134 points by fla 10y ago

haldean 10y ago
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 10y ago
  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/tree/master/hipify-clang https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/tre...
- hatsunearu 10y ago
  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?
conistonwater 10y ago
My first question was "what about OpenCL", and they seem to address it here: https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blob/master/docs/markdown/hip_faq.md#how-does-hip-compare-with-opencl https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/blo...
- joe_the_user 10y ago
  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 10y ago
    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 10y ago
      > 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-drivers/open-source-amd-linux/881414-amd-radeon-rx-480-on-linux?p=882080#post882080 https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... [2] https://github.com/RadeonOpenCompute/ROCm/issues/30 https://github.com/RadeonOpenCompute/ROCm/issues/30
    - pjmlp 10y ago
      > 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.
  - se6 10y ago
    > 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.
- dharma1 10y ago
  https://github.com/hughperkins/cuda-on-cl https://github.com/hughperkins/cuda-on-cl
aamederen 10y ago
Meanwhile, still nobody cares about compute shaders.
- exDM69 10y ago
  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).
m_mueller 10y ago
What about Fortran support?

134 points by fla 10y ago

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 10y ago
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/tree/master/hipify-clang https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/tre...
hatsunearu 10y ago
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?

conistonwater 10y ago

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

joe_the_user 10y ago
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 10y ago
  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 10y ago
    > 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-drivers/open-source-amd-linux/881414-amd-radeon-rx-480-on-linux?p=882080#post882080 https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... [2] https://github.com/RadeonOpenCompute/ROCm/issues/30 https://github.com/RadeonOpenCompute/ROCm/issues/30
  - pjmlp 10y ago
    > 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.
- se6 10y ago
  > 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.
dharma1 10y ago
https://github.com/hughperkins/cuda-on-cl https://github.com/hughperkins/cuda-on-cl

aamederen 10y ago

Meanwhile, still nobody cares about compute shaders.

exDM69 10y ago
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).

m_mueller 10y ago

What about Fortran support?