I raised an eyebrow but I have only the vaguest notion of how the hardware works and what a driver might have to manage.
ehh, no.
almost all of this are header files
>Meanwhile the open-source NVIDIA "Nouveau" driver is around 201k (21.7k blank lines, 24.3k lines of comments, and 155k lines of code). Or the Intel i915 DRM kernel graphics driver is around 381k lines via the same cloc judgment.
so it seems like GPU driver is around 1% of kernel's code
and you start thinking why actually kernel has this much code if GPU (out of all software) needs just around 1%.
The reason is, GPU drivers are basically complete operating systems, just for the secondary computer we call the GPU instead of the CPU.
The large majority of the "Linux kernel code" is drivers, but the large majority of the driver code is the GPU drivers. And the GPU doesn't have its own collection of drivers for every network chip or USB controller ever made.
The second biggest part of the Linux kernel is "arch/" which is the architecture-specific stuff, but GPUs don't really have that either -- a given vendor more or less corresponds to a platform architecture, but if you compare it to, say, "x86/" that's only ~11% of "arch/" and <1% of the kernel.
The reason the GPU drivers are so big is that they're gibberish. Instead of specifying an interface to interact with the GPU in a sane way, they're full of magic numbers that seem to map a (large, overly complex) API interface into the values you pass to the GPU to call the API functions implemented by the GPU's firmware, which is the actual GPU "operating system" but the vendors want to keep as a black box.
Which is obviously counter-productive because it keeps users from optimizing for their GPU, which would make things run faster on it (or have fewer stability bugs), which would make more people want to buy them over a competitor's, which was supposed to be the reason for the secrecy.
Nouveau will bring up you're Linux desktop just fine and connect all your monitors.
It will run OpenGL apps and light games.
Last time I checked it could not boost the clock and push most chips to high performance mode.
This is mostly 100% Nvidia's fault of not opening up the specs.
Otherwise what nouveau has been able to reverse engineer is just amazing.
The nouveau driver is so much less painful to use, it just works completely seamlessly. If you don't need the extra performance, it is not worth the trouble to install the Nvidia blob.
Probably if AMD wanted to spend the time, they could compress it down to a fraction of it's current size.
0: https://github.com/spdk/spdk/blob/master/include/spdk/nvme_s...
Even on small m.2 style standalone drives, your looking at code, which not only handles the details of managing flash error correction, wear leveling, garbage collection, etc, etc, but all the code required to manage the thermal, voltage, pcie link training, etc of the 2-5 or so microcontrollers embedded in the drive and possibly an RTOS or two hosting it all.
Never mind fabric attach (DPU?) NVMe devices which do all that, plus deal with thin provisioning, partitioning, deduplication, device sharing, replication, RAID, etc, etc. Frequently themselves embedding a Linux (or similar level of complexity OS) kernel in the control plane.
I'm not familiar with AMD's GPUs, but have done some "bare metal" Intel GPU programming, and there's definitely a lot of commonality between different generations going all the way back to the i810.
GPU or CPU? If talking about the latter only two [four] should count (ARM & x86 [+ [* 2 64BitVersion]]. If you meant the former forget my comment.