[einpoklum]

> 1. Ever heard of Nights and Visual Studio plugins?

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.

[pjmlp]

While SYSCL might stand a chance against CUDA, thanks to it being backend agnostic and a compiler neutral standard, C++ for OpenCL is a clang specific project which remains to be seen if it ever will get any adoption.

> 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...

[einpoklum]

> C++ for OpenCL is a clang specific project which remains to be seen if it ever will get any adoption.

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.