A pathetic attempt to lock developers into their hardware.
Their decision making seems rational, of course it's not ideal if you're consumer. We would like the ability to bid off NVidia with AMD Radeon.
Convergence to a standard has to be driven by the market, but it's impossible to drive NVidia there because they are the dominant player and it is 100% not in their interests.
It doesn't mean they're a bad company. They are rational actors.
However, this notably doesn't cover binaries, which are GPU vendor specific in that case, so AMD for example would have to provide a C++ compiler implementing stdpar for GPUs targeted to their hardware.
Ah-ha, you've caught us! Our plan is to lock you into our hardware by implementing Standard C++.
Once you are all writing code in Standard C++, then you won't be able to run it elsewhere, because Standard C++ only runs on NVIDIA platforms, right?
... What's that? Standard C++ is supported by essentially every platform?
Darnit! Foiled again.
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.
That's what NVIDIA understood and made them what they are today.
They did publish the specs, it's open source. BTW, Nvidia's acquisition of ARM means that it will be selling CPUs.
P.P.S., the driver runs on the host, so your proposed alternative doesn't address the point you think you're making.
Nvidia buying ARM is not a good news for me. The same way I don't like them making software, I also don't like them selling CPUs or seafood. They are good at GPUs and that's OK.
The drivers are usually running in the kernel space and do not involve much of interaction with users. Firmware, on the other side, is hardware-close software and can be gradually replaced by specific hardware continuous improvements without the user/software or the OS noticing.
libcu++ is a fork of LLVM's libc++, which we do not control. We contribute upstream and engage with that community.
libcu++ is an implementation of the C++ Standard Library, which is controlled by an ISO standardization committee, which has about ~300 members, 10 of whom work at NVIDIA.
> The same way I don't like them making software, I also don't like them selling CPUs or seafood. They are good at GPUs and that's OK.
We employ more software engineers than hardware engineers. We don't sell hardware, we sell software + hardware.
We manufacture and sell CPUs today. I like to think we're quite good at it.
> The drivers are usually running in the kernel space and do not involve much of interaction with users.
Incorrect. The core part of the driver, called the Resource Manager (RM), runs in the kernel space. Each different SDK (CUDA, OpenGL, Vulkan, etc) has its own "user mode driver", which is a shared library that interacts with RM. It's hard to say what the split is, but I'd say roughly half of what you think of as "the driver" is in user mode.
> Firmware, on the other side, is hardware-close software and can be gradually replaced by specific hardware continuous improvements without the user/software or the OS noticing.
Firmware runs on the GPU. You can't do everything from the GPU.
But neither firmware nor drivers have anything to do with the toolchain that you use to write heterogeneous programs. That's what this is a part of.
This is an open source library that meets the C++ standard, which is designed and contributed to by many companies, not just nvidia. Like AMD and Intel, Nvidia does release some proprietary things that your complaints might apply to, but this is not one of them.
Raspberry Pi initially shipped with such a graphics stack, with the Arm side just being a communication driver in the kernel and an RPC stack in user-space.
It isn't a good idea (for numerous reasons, including security) and is even more closed in practice than what ships today.
+ RPC needed all the time... with its latency would tank the performance
It'd also be not tinkerable at all unlike what we have today, it's exactly advocating for the opposite of open.
Correct.
> Keeping the software part in firmware lets customer free to use any kind of OS.
Do you mean firmware, or firmware and driver?
You can't do everything in firmware.
> Using host cpu and memory is bad design IMHO.
How do you propose that you program the GPU then?
The CPU has to interact with the GPU. Some software has to manage that interaction.
That said, we are not talking about either a driver or firmware. This is a part of our toolchain. It is a library that you use when writing a heterogeneous program.
The majority of software written at NVIDIA (by any metric, lines of code, number of projects, etc) runs either solely on the CPU, or on both the CPU and the GPU.