By the way, let me ask a couple of stupid questions about GPUs:
Do RISCV-style free GPU projects exist or would they be unviable because of some specific properties of the GPU nature?
Why even bother implementing actual rendering in hardware when you can just implement fast general-purpose calculations and use them to accelerate software rendering? CPU-based software rendering did pretty well for the first versions of Unreal and Half-Life, I imagine it could also make sense today if accelerated with something like CUDA.
> when you can just implement fast general-purpose calculations and use them to accelerate software rendering?
They are optimizing for different things.
CPUs are optimized for single-threaded performance, i.e. lower latency. They only have a few cores, but these cores are spending billions of transistors implementing cache hierarchy, reordering instructions, predicting branches with neural networks, predicting indirect branches, prefetching data from RAM, executing instructions speculatively with the ability to rollback, etc. All these things are very complicated, but they do help with latency.
GPUs don't care about latency. They only care about throughput on massively parallel workloads. For all these cases when a CPU needs to do something smart to minimize latency, GPU cores simply switch to another thread to do something else in the meantime. That's how they have count of cores measured in hundreds if not thousands.
One more thing, high-end CPUs run at ~4GHz to minimize latency, GPUs at 1-2GHz to maximize power efficiency.
The result is about an order of magnitude difference in throughput. Ryzen 9 5950X peaks at 1.8 TFlops FP32, yet similarly priced Radeon RX 6800 XT peaks at 17 TFlops.
I didn't mean using a CPU for rendering. I meant building a GPU without graphics-specific functions. Imagine a 3D graphics driver/engine which takes a normal GPU of today and uses its CUDA/OpenCL functions to calculate everything it needs to render graphics without using the GPU's OpenGL/Direct3D functions. I wonder if such an engine could be viable and if we could design a GPU which would have no actual graphics-specific functions (only implementing e.g OpenCL) and still empower the graphics engine in a reasonable degree.
IANA GPU expert, but AFAIK modern GPUs are pretty much are that already: massively parallel general-purpose CPUs.
It's the GPU driver layer that takes either the compute or graphics instructions and converts them into the particular instruction set/microcode used by the "CPUs" in the GPU. In a sense that code is "recompiled" (but may be cached) every time a "program" is run.
[0] is a post that talks about reverse-engineering the interface to the GPU in the Apple M1, a lot of which consists of what I've just described, so reading that series might help understand.
The reason I feel interested in this is it seems we wouldn't need a vendor/model-specific 3D graphics driver in such a case. The vendors could just provide libraries implementing a standardized set of general purpose parallel calculation acceleration functions (e.g. OpenCL) and an app (or a vendor-agnostic 3D driver) would just use the vendor-agnostic interface to accelerate rendering-related calculations and then output to something like a VESA driver.
We still seem to be pretty far from there though.
It is also worth mentioning that actual 3D drivers have always been buggy. Seeing a mess of visual artifacts above or in place of the actual picture still is not and has never been anything unusual when using a driver which utilizes hardware graphics rendering functions. This is what got the idea into my mind in the first place. Too tired of swapping driver versions and hoping for the best. It's been more than 2 decades already and this still happens.
Another motivation might be just reducing the chip complexity which might occasionally help in improving power efficiency in some usage scenarios.
What you described is fairly close to how it works on Windows.
Vendor-specific GPU drivers don’t implement the complete Direct3D. They only do low-level hardware dependent pieces: VRAM allocation, command queues, and the JIT compiler from DXBC into their proprietary hardware-dependent byte codes (this last one is in the user-mode half of these drivers).
Direct3D runtimes (all 3 of them, 9, 11 and 12) are largely vendor-agnostic, and are implemented by Microsoft as a part of the OS.
I see. Thank you. This is curious to know. However, I have tried the Visual Studio 2019 WPF designer on a new laptop recently and it shown black artifacts on the form and complete garbage in place of the components palette. I've installed the graphics driver from the GPU vendor website and that fixed the problem. The driver used before that was a supposedly stable version developed by the same vendor and shipped by Microsoft. This led me to the conclusion there still is a lot of weird hardware-dependent stuff happening under the hood.
WPF is relatively old tech, built in 2006 on top of DirectX 9.0c and unfortunately stayed that way ever since. Probably that’s why the bug in the GPU drivers went unnoticed.
In my experience, in modern world the newer ones like D3D11 and 12 are generally more reliable.
If I would be managing the relevant division at Microsoft, I would consider deprecating D3D9 support in drivers and kernel, instead rewrite d3d9.dll to emulate the API in user mode on top of D3D12.
Microsoft already did similar trick long ago for OpenGL. Starting with Windows Vista they were emulating GL (albeit very old version of GL) on top of DirectX kernel infrastructure, unless the GPU vendor shipped their own implementation of a newer version of GL.
More recently, third-party developers have re-implemented Direct3D 9 on top of Vulkan (which is very comparable to Direct3D 12 feature wise), the results seem good: https://www.reddit.com/r/pcgaming/comments/hirdfp/dxvk_is_am...
There seem to be such a project actually, just released to open source:
https://github.com/microsoft/D3D9On12
https://devblogs.microsoft.com/directx/open-sourcing-direct3...
But it seems you have to actively enable it in the development time, the OS won't just silently do this on itself and I doubt Microsoft or anybody else is going to update their software to do so.