A lot of hardware has builtin software, either inside a firmware or as a driver. Keeping the software part in firmware lets customer free to use any kind of OS. Using host cpu and memory is bad design IMHO.
Can you elaborate on what you mean? This is an open source library for developers to write code that can compile without changes on both CPU and GPU. This solves a problem that can’t be solved in firmware, and this is not a case of nvidia using cpu and host memory - whether to use cpu and host memory is strictly up to the developer.
Sorry, related to cpu and host memory , I was wrong. I meant : having the GPU seller control/write code that plays with host cpu and memory is bad. Let people use their own gcc/g++ or whatever compiler and publish the specs. Unless they also start selling CPUs.
This is gcc or whatever compiler, it is not nvidia's compiler. This library does not give nvidia any "control" over host operations, it gives developers another tool.
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.
I did not say the library controls anything, Nvidia controls the library : its features, its roadmap, its bugs corrections, development efforts (people) etc. All these choices are made by Nvidia. It is not just another tool , it is the tool that is closest to hardware evolution.
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.
> I did not say the library controls anything, Nvidia controls the library : its features, its roadmap, its bugs corrections, development efforts (people) etc. All these choices are made by Nvidia.
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.
> It is not just another tool , it is the tool that is closest to hardware evolution.
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.
> Keeping the software part in firmware lets customer free to use any kind of OS
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.
Raspberry Pi is not marketed for graphics as nvidia is doing with their GPUs. What I mean is that firmware is running on a usually small cpu and memory that is sold as a part of the GPU. No security issues here as the main security issue is to plug the whole GPU inside your PC.
That sounds like vendor binary blob sdk libraries, only everything is an rpc and you're not even in the same memory space, aka distributed computing, except you have no control over the device stack. Sounds kinda awful to me.
> A lot of hardware has builtin software, either inside a firmware or as a driver.
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.