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