Not sure how much use it will be, but AMD's GPUOpen initiative recently released a tool[1] that translates native CUDA code to portable C++ that can be recompiled into either CUDA or OpenCL. I haven't played with it at all so I can't verify how well it works.

[1] https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP

The difference between the kernel languages is minimal, many kernels can be translated with basic search & replace.

The difference is in the scaffolding (CUDA is easier but less flexible), and pre-existing libraries on offer.

If you're going to be writing the kernels yourself then it is easy to maintain both versions and it if it is for learning it doesn't matter at all (but I prefer the standard that works on all my machines).

OpenCL doesn't do Fortran, C++, Haskell or .NET.

Well, OpenCL 2.1 does do some C++ (not as much as CuDA with Pascal), but isn't widely available anyway.

There are plenty of zero-cost C++ wrappers available, including the official bindings. Most people who use OpenCL from C++ tend to accumulate their own convenience wrappers over time. The rest of those languages have fairly easy interoperability with C code and therefore access to the C api, though some may also have established convenience libraries. I wouldn't suggest .NET or Haskell for most serious GPGPU work, but Python, Julia, Fortran and others are frequently used. The PyOpenCL library is particularly excellent.

If you were referring to the kernel language (a restricted subset of C99), I don't find that to be a disadvantage in practice. While CUDA supports a fairly useful subset of C++ (most notably, templates), I still find host-side metaprogramming to generate kernel code to be a much more useful approach in most cases. Of course your preferences may vary, but I haven't seen many experienced GPGPU people express dissatisfaction with this point.

False. The official wrappers support C++ from OpenCL 1.0 on. Maybe this isn't obvious because the C++ bindings were introduced later, but they're backwards compatible and you can set the target API level. (And of course you use 1.2 if you need to support lagging vendors such as NVIDIA)

I have no idea about the other languages but surely other bindings must exist?

No one is speaking of wrappers here, rather C++ kernels, which is what matters, a full C++ experience.

> I have no idea about the other languages but surely other bindings must exist?

Yeah, the usual poor man's solution of generating C code, thus introducing two compilation steps, without any debugger support.

Anyone know whether GPU Ocelot actually works well? In theory that should allow you to run CUDA on your AMD hardware via OpenCL.

I always wanted to try it, but on the flip side the fact that AMD was starting their own project to do the same thing doesn't fill me with confidence that GPU Ocelot is worth my time.

I haven't used it myself, because I looked at it and saw that it's been unmaintained for over a year, has no adoption and requires ancient versions of CUDA and LLVM. The concept is interesting, but at this point the project seems dead to me.