Comment by joe_the_user | Hacker News Reader

Comment by joe_the_user | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com