2. OpenCL 2.x allows for C++(ish) source code. Not sure how good the AMD support is though.
2. OpenCL 2.0 was a failure, so OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped and SYSCL is now backend agnostic.
Those are apples and oranges... also, you forget cuda-gdb.
> OpenCL 1.2 got renamed as OpenCL 3.0. C++ bindings were dropped
Well, yes, but also no. They were made optional, and transitioned to some other C++-cum-OpenCL initiative:
https://github.com/KhronosGroup/Khronosdotorg/blob/master/ap...
I'm not exactly sure how this differs and what's usable in practice though.
> For C++ kernel development, the OpenCL Working Group has transitioned from the original OpenCL C++ kernel language, defined in OpenCL 2.2, to the ‘C++ for OpenCL’ community, open-source project supported by Clang. C++ for OpenCL provides compatibility with OpenCL C, enables developers to use most C++17 features in OpenCL kernels, and is compatible with any OpenCL 2.X or OpenCL 3.0 implementation that supports SPIR-V™ ingestion.
https://www.khronos.org/news/press/khronos-group-releases-op...
About adoption - you're right. But about being Clang-specific - that's not an issue. That is, OpenCL is also specific to an OpenCL compiler; so the fact that compilation from C++-for-OpenCL to SPIR-V is clang-based is not a problem. We can still compile our host-side code with whatever compiler we like, but the runtime compiler of OpenCL C++ kernels will be clang-based.