E.g. if CPUs would have closed ISAs and heavily guarded IPs, you'd also need a 'driver' and an 'OpenCPU API' to make any use of them (of course the public ISA of a CPU is essentially the driver interface baked into the hardware).
The other big difference is focus on decent single-thread performance for CPUs versus performing thousands of small tasks in parallel on GPUs, but each one slowly. This difference causes a different programming model (e.g. running an entire application in a single 'main' function from start to finish, versus spawning small specialized tasks which are running across hundreds of threads).
And the specific problem with Vulkan is that it tried to solve two conflicting requirements: on one hand being an explicit low-level API without 'magic abstractions', on the other hand supporting very different GPU architectures (especially the mobile GPU zoo). The resulting mess was quite predictable to be honest...
[–] david-gpu 2 days ago
[–] flohofwoe 2 days ago
Those hardwired fixed-function parts are getting fewer and less important though (ok, and then raytracing units entered the scene...). Also AFAIK something like a texture sampling operation is indeed a 'fancy instruction'(?), even though the actual texture sampling is done by a 'fixed function' hardware unit.
> This also necessitates a device driver to manage scheduling, synchronization, etc. with the main OS.
I bet this type of GPU/CPU handshaking work could also be baked into the hardware (similar to CPU mirocode) and exposed via a standardized memory mapped IO interface (or whatever the current mechanism is for letting the CPU control the GPU). E.g. a CPU also implements similar protocols to talk to the rest of the computer system (e.g. memory and other CPUs), but this is mainly implemented as "hardware protocols" - drivers "just" offer more flexibility for hardware vendors because they can delegate the standardization into software.
...also a lot of the "CPU / GPU software ecosystem" was probably shaped by CPU and GPU vendors historically being different companies, and once the big consolidation started, the conventions were already set in stone.
[–] david-gpu 2 days ago
There is more machinery internally than what the user can see. Even "low level" APIs hide quite a lot of the internal complexity.
> Also AFAIK something like a texture sampling operation is indeed a 'fancy instruction'(?)
Yes, and no. The "I want to sample this texture" part looks like a fancy instruction to the shader processor. But there is a fair amount of setup that needs to be done before and after, and that is the responsibility of the device driver. Stuff like: where is the data, how is it arranged in memory, how it is to be sampled, etc.
As you point out, the texture units are coprocessors inside the coprocessor that is the GPU itself. It is turtles all the way down. Think of a GPU as a whole network of processors inside a chip, some of which are hidden from the application programmer.
> I bet this type of GPU/CPU handshaking work could also be baked into the hardware (similar to CPU mirocode) and exposed via a standardized memory mapped IO interface (or whatever the current mechanism is for letting the CPU control the GPU)
Attempts have been made. Last time I checked, they had not been very successful, but I have not kept up with the latest developments after retirement.
The way this normally works is that there is a circular command buffer where the CPU inserts commands and the GPU consumes them. It works; there is nothing wrong with it. It is the obvious way to handle asynchronous coprocessors.
> E.g. a CPU also implements similar protocols to talk to the rest of the computer system (e.g. memory and other CPUs), but this is mainly implemented as "hardware protocols" - drivers "just" offer more flexibility for hardware vendors because they can delegate the standardization into software.
I suspect you underestimate the amount of setup that is necessary to drive a GPU. And the amount of asynchronous resource management involved.
Let me put it this other way: the people doing this for a living for decades know what they are doing. There have been attempts to try to make GPUs that behave more like CPUs in terms of how they are driven, and they have not been very successful so far, to my knowledge. AMD acquired ATI back in 2006, so it is not like there hasn't been enough time for the concept to cook in the oven. See also Intel's Larrabee.
First, GPUs aren't simply "highly parallel CPUs", they also contain a whole lot of fixed function hardware that is specialized for real-time computer graphics. This hardware isn't exposed as "fancy instructions", it is set up in other ways, which is achieved through a device driver.
Second: GPUs are coprocessor, separate from the CPU where another OS is running. This also necessitates a device driver to manage scheduling, synchronization, etc. with the main OS. Because, in case you were not aware, the GPU itself runs its own little operating system, although it is rarely called that.