Only the user mode part of the driver is replaced, the kernel interface is actually shared between the closed source and the open source driver. So it's just loaded like a DLL/.so and hooked up to the API.
This is only possible because of a very specific quirk of Linux: the interface between the kernel and user mode halves of the GPU driver is considered as sacrosanct as normal Linux syscalls[0]. If you want to get a graphics card driver in kernel you have to get your driver's UAPI approved by the kernel maintainers because it will be supported in Linux until the end of time.
No other operating system does it this way, nor will this work on Nvidia proprietary drivers. Everywhere else, the point of demarcation for graphics is OpenGL, DirectX, Metal, or Vulkan entrypoints in userspace. To be clear, there IS a UAPI here too - hardware isolation demands it - but it breaks constantly and nobody bats an eye. If you were willing to deal with that fragility, you could do the same trick on Windows or macOS.
[0] For those unaware, Linux has a very explicit policy of never breaking userspace. That means no ABI changes whatsoever.
> For those unaware, Linux has a very explicit policy of never breaking userspace
But has no qualm with constantly refactoring the kernel side of the coin for the most minor of reasons, which causes endless trouble when it comes to supporting out of tree drivers and is the true reason why Android will never be able to provide long term support. SOC manufacturers are not interested in the churn involved in updating their drivers to support the newer kernels that come with new android versions. Most often, it's because they want to keep their driver proprietary, but it is not the only reason, there is a cold hard truth about the nature of the market: new phones are released at a high cadence, while the process of mainlining a driver into upstream linux kernel is arduous, depending on the attitudes of kernel maintainers, truly painful, and no company out there could see any value in waiting for this process to end before releasing their hardware onto the market. Since they're already going to make it out of tree and release it as is, why would they bother? a year later, they'll repeat this process again, and again. Then Android updates, and the devices are obsoleted.
On the other hand, you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11. Windows doesn't constantly break your not-maintained-by-microsoft drivers with newer versions of their kernel.
For the part that most people care about (which is the userspace side, that comes from the Mesa Project) you can freely update it to whatever is the latest version without really having to care about the kernel side. The only point at which the kernel side of the GPU equation actually matters for Mesa is when new HW comes out.
>>you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11
MS is certainly well known for breaking Windows drivers across major releases. The only reason that Win10 and 11 driver is the same is because Win10 and 11 are more or less the same thing.
To put a finer point on driver breakages... part of why Vista was so disastrously bad at launch was specifically because they'd drastically changed the DirectX kernel driver model to support DWM[0]. Nvidia in particular was responsible for a third of all Vista crashes, with another third being ATI (now AMD RTG). WDDM was a moving target right up until launch and it took about a year for Vista to actually be usable[1].
>MS is certainly well known for breaking Windows drivers across major releases. The only reason that Win10 and 11 driver is the same is because Win10 and 11 are more or less the same thing.
Not quite accurate, it depends on whether a new version of Windows has a significantly newer kernel.
Windows 2000 and Windows XP (and all its derivatives) share the NT5.x kernel, and thus drivers for any of them generally work in the others. Likewise Windows Vista/7/8/8.1 which all share the NT6.x kernel, and Windows 10 and 11 which share the NT10.0 kernel.
In other words, it's pretty common for Windows users to experience major driver breakage every time they upgrade to a new major version of Windows. Because it was pretty normal to go from Windows 9x to XP (skipping 2k), then skip Vista and not upgrade until 7, then skip 8 and 8.1 and not upgrade until 10. The exceptions were mostly if you bought a new computer that had one of the more disappointing releases preinstalled, but in those cases driver breakage would have been much less of a concern anyways.
>In other words, it's pretty common for Windows users to experience major driver breakage every time they upgrade to a new major version of Windows
This is really a high level arguing in bad faith here. Windows XP was released in 2001 and mainstream support ended in 2009 with the last security update in extended support being in 2014. Vista to 8.1 covers 2006 to 2023, that's 17 years of having compatible drivers. Windows 10 was released in 2015, 8 years ago, with 11 having a compatible driver model and will go for many years still.
What does "common" to experience breakage is supposed to mean here? you call this common? meanwhile you can't even get a Google Pixel, the official Google phone, to be supported more than 3 years of feature update, with 2 more years of security updates. This is all because supporting the linux kernel is a pain in the ass.
No other operating system does it this way, nor will this work on Nvidia proprietary drivers. Everywhere else, the point of demarcation for graphics is OpenGL, DirectX, Metal, or Vulkan entrypoints in userspace. To be clear, there IS a UAPI here too - hardware isolation demands it - but it breaks constantly and nobody bats an eye. If you were willing to deal with that fragility, you could do the same trick on Windows or macOS.
[0] For those unaware, Linux has a very explicit policy of never breaking userspace. That means no ABI changes whatsoever.