top | item 34078608

(no title)

epmaybe | 3 years ago

I don’t think there’s truly a competitor but opencl is the alternative to shoot for. Otherwise for machine learning purposes amd helps develop ROCm.

discuss

order

pjmlp|3 years ago

OpenCL is hardly an alternative, plain old C, using compilation from source at runtime, with very basic tooling available.

Versus a polyglot compiler infrastructure, IDE tooling that includes shader debugging, and a rich ecosytem of GPU based libraries.

Even with SYSCL and SPIR-V, that has hardly improved, and while Intel bases oneAPI on top of SYSCL, that naturally also goes beyond the standard.

ColonelPhantom|3 years ago

What do you mean by a polyglot compiler infrastructure? Are you referring to the fact that CUDA source is single-file (your host and device code are in the same compilation unit?) Or do you mean that you can ship the same binary to different GPU architectures?

SYCL solves the first issue, and SPIR-V solves the second one. (OpenCL mostly avoids the issue in general though by making you ship source which is then compiled by the driver, but SPIR-V allows you to ship a 'binary' instead).

No clue as for debugging and IDE tooling, but I did find a rocgdb binary on my Linux ROCm installation (which is for HIP, not SYCL). No clue what oneAPI offers for debugging.

Furthermore, Clang (and hence clangd) speaks HIP and I think SYCL too. So the non-runtime IDE tooling should work.

Finally, a lot of GPU libraries are I think available for ROCm/HIP too. It's unfortunate that the HIP stack sucks enormously in other ways.

amelius|3 years ago

Shouldn't we have an API that can speak to both CUDA and opencl? Or is opencl sufficiently capable?