The Linux Kernel Tree About To Hit 40 Million Lines, AMD Driver Above 6 Million Lines
Posted by kingsaso9@reddit | linux | View on Reddit | 98 comments
Huge_Item3686@reddit
Even acknowledging it is really a driver set, 15% of the whole linux codebase just being amd doing amd things is crazy to me.
varsnef@reddit
That is what I see when compiling a custom kernel...
-3 minutes for the kernel. 3+- minutes for AMDGPU or out of tree nvidia-drivers, and almost another -3 minutes for LTO full.
ThatsALovelyShirt@reddit
I thought LTO Thin or Thin Dist was better for building the kernel.
varsnef@reddit
I have heard that.
I just used full because it took so long. Almost as much time as the AMDGPU driver took to compile.
totallynotbluu@reddit
What system are you compiling on?
Salander27@reddit
Either a very beefy one or they're only compiling drivers for the PCs specific hardware. Likely the latter.
varsnef@reddit
Yeah, it's the latter. A standard "Distro" config takes an hour.
varsnef@reddit
Just an AMD 5700. with a light kernel config. It's just crazy at how big GFX drivers are.
Simple_Law7232@reddit
Graphic cards are basically separate computers with proprietary architecture and graphics driver job is to translate/compile commands and shader code of open libraries (which there are multiple types and versions of) to while doing a ton of optimization on top of it - it takes a lot of code to do so.
Erchevara@reddit
That's just the AMD graphics part. I bet there's a whole lot more for the CPU stuff, but that may be entangled with Intel.
The real question is how much is in Intel GPU code. It's a bit younger, to be fair, but that might explain why there's quite a big gap between the AMD and Linux experience on Linux. I have a Lunar Lake CPU and it barely has any GPU support on Linux with the latest kernel. It's probably worse than Nvidia before they started playing along, but at least it's all fuss-free for the user.
ParaboloidalCrest@reddit
Excuse my ignorance please: I've always wondered, why is AMD kernel built into the kernel, unlike nvidia?
Level0Up@reddit
Because AMD supplies drivers and nvidon't.
ParaboloidalCrest@reddit
Follow-up if I may: Why isn't the AMD-supplied driver a separate package?
tchernobog84@reddit
"mangled"? It's just a driver like any other, built as a module.
Being upstream means less breakage on code changes by other people.
It's more economical and friendlier to maintainers and distros alike.
Internet-of-cruft@reddit
u/ParaboloidalCrest: AMD is being a first class maintainer of drivers for their hardware platform.
They are playing by all the rules every other maintainer of code in the Kernel is.
Nvidia has no such expectations and we're at their mercy.
BinkReddit@reddit
And this is why I vote with my dollars and don't buy Nvidia.
anthony_doan@reddit
Those leather jackets aren't free buddy.
Nvidia need to make money to buy them for Jensen.
Internet-of-cruft@reddit
I apologize for stepping out of line, you're completely right.
Western_Objective209@reddit
a design decision decades ago to make things easier, but now it's starting to feel silly tbh
Business_Reindeer910@reddit
no, it's not just to make things easier.
Western_Objective209@reddit
if you're talking about ABI stability then yes it's to make things easier; the driver vendors can just bump the kernel version, run CICD, and release a new version.
Business_Reindeer910@reddit
because the kernel has no stable API. third party drivers are hard to manage and that is by design.
ParaboloidalCrest@reddit
Right. I guess what I"m imagining is a micro-kernel, which is not he case here.
apatheticonion@reddit
It's actually a huge point of controversy in the kernel space.
On the one hand, in-tree drivers ensures the kernel can be optimized without worrying about the public ABI of drivers.
On the other hand, not allowing for dynamically loading drivers (like Windows) causes companies who want to hide their IP to maintain long-running private forks of the kernel.
This is why Samsung Android is using Linux 4 or whatever. It's also why you can't just take the drivers from Samsung's linux kernel and plug them into a normal kernel and run Ubuntu on your phone.
Google tried to solve this on Android with their GKI project - which essentially adds a stable driver ABI to Linux + Android and force phone vendors to build for it... but it sucks and hasn't realised the benefits it set out to accomplish.
Nvidia have a driver shim in the Linux kernel, which is similar to GKI in that it's just an API exposed from their kernel driver which looks for their external driver file and talks to that (kind of like a micro-kernel).
This isn't practical for everyone, of course.
Personally I think it's pragmatic to offer a stable driver ABI in the kernel - but I also don't want to see a disincentive for vendors to upstream their drivers and leave them unmaintained as that would likely kill Linux over the years.
Berengal@reddit
Linux does allow dynamic loading of drivers though. That's how modules work. You can dynamically load and unload them with e.g. modprobe and systemd.
apatheticonion@reddit
You can dynamically load modules but they need to be built for that kernel version and compiler and compiler configuration.
For instance, a hypothetical Nvidia driver compiled for Fedora would not work on CachyOS. It would also need to be recompiled when a new kernel is released.
That makes it impractical to ship a binary driver that can be dynamically loaded that way.
Firewolf06@reddit
this is a big part of why building the kernel is something people actually do. you can massively cut down on image size by removing modules/drivers you dont need. this makes it very slightly more performant but significantly cuts boot time, which can be critical for dynamic scaling
JockstrapCummies@reddit
Until the day when you plug in some peripheral and it just doesn't work. You scratch your head for the longest while until you realise you compiled your own slimmed-down kernel which didn't include this driver.
Business_Reindeer910@reddit
It turns out that once you bring all the code in one place, a lot of the drivers for similar hardware are not that much different from each other. That's why it's only 40 million lines! Graphics drivers are obviously outliers here.
ParaboloidalCrest@reddit
Fair enough. If there's no standard API, then the best we could do is to deduplicate the code across all the open-source drivers in hand. Makes sense. Although this seems like monstrous amount of work.
Business_Reindeer910@reddit
oh i missed one of your wording here. There is a STANARD API.. It is just not a STABLE API.
Business_Reindeer910@reddit
That's the work that's led linux to be relied upon more and more.
It's also why we we can end up with programs that can talk to multiple kinds of hardware (like openrgb) rather than tons of vendor specific programs.
tinypocketmoon@reddit
This design choice still feels really weird even after so many years. No stable kernel API nor user-space ABI does hinder adoption a lot
maowtm@reddit
Linux has a stable user space ABI tho?
yawara25@reddit
In theory
Business_Reindeer910@reddit
It's also forced more open source drivers that conform to standard interfaces, and that's a tradeoff I'm willing to accept!
arades@reddit
Linux is a monolithic kernel, everything lives in one monolithic source tree. You're pointing out what people have pointed out since at least 1990, that it would be nice if everything didn't need to be all rolled into one source tree. Windows and MacOS are hybrid microkernels that readily separate drivers into separate binaries. Linux allows dynamic module loading (sometimes), but it's not how it's designed and will always work worse than being built in. You see this with nvidia drivers. They consistently perform worse than windows counterparts, only work with a small number of kernel versions, and they require the DKMS system to be enabled, which a lot of hardened kernels turn off because it's an enormous attack surface. It also breaks SecureBoot unless you go through the effort to sign and enroll your own key.
I for one enjoy that any AMD or Intel GPU I plop into my machine works with zero configuration. The situation on windows where you have to nuke all evidence of previous driver, limp along with VGA driver while you install some multi GB blob is infinitely worse.
That being said, it's worth noting the AMD driver code is not written, but generated, and that's why it's the size it is. AMD maintains some manifest files and a code generator that spits out all the code for each GPU. That results in insanely high lines-of-code, but that also often makes it really performant.
Business_Reindeer910@reddit
This is has nothing to do with it being monolithic or microkernel like!
crystalchuck@reddit
In my understanding, it does make a difference whether the kernel architecture is monolithic or not (however, not the repo ofc). In a classic microkernel architecture, drivers are userspace programs that have to do round trips to the kernel for many things. The XNU and NT kernels mitigate this by permitting kernel-mode drivers in their hybrid kernel architectures.
Business_Reindeer910@reddit
no, i meant that the performance difference with linux vs windows (not some other OS) has nothign to do with microkernel vs monolithic kernel.
r0flcopt3r@reddit
The kernel is more or less just a collection of drivers.
NotFromSkane@reddit
ALL normal drivers live in the kernel. It's the outliers that are out-of-tree hacks.
Internet-of-cruft@reddit
Correct me if I'm wrong, doesn't your kernel get tainted when you're running Nvidia drivers, since they're out-of-tree?
monocasa@reddit
Yes.
NotFromSkane@reddit
I don't even know what you mean by tainted here
Internet-of-cruft@reddit
Here's a reference: https://docs.kernel.org/admin-guide/tainted-kernels.html
Nervous-Cockroach541@reddit
The kernel has a collection of modules, which can all be included or excluded when you build it.
McFistPunch@reddit
So you dont have to rely on distros to support hardware. Or install packages. Your shit just works off the rip.
orbvsterrvs@reddit
AMD builds and releases their driver for Linux, NVIDIA does not. There is an "open source" NVIDIA driver now, but it calls into their firmware (proprietary) so often that it's something of a compatibility layer as opposed to a true driver in some senses.
NVIDIA is much more invested in Linux now with AI workloads suddenly bringing lots of interest and money. Hopefully they stick around and continue to keep things open, rather than pursuing a "walled garden" approach with hardware+drivers from within the kernel.
gmes78@reddit
I wish people would stop using this bullshit argument.
Pretty much every device has firmware of some kind, and the vast majority are closed source, including Intel's and AMD's GPU firmware.
The only reason people make this argument is that they're looking for any reasons to complain about Nvidia (and don't actually care about proprietary firmware), or they just heard the argument from someone else and repeat it because they don't know any better.
Business_Reindeer910@reddit
Nah, ther'es still legit criticism to be had, it's just more on the userspace side now.
gmes78@reddit
That is entirely beside the point I'm making. I'm not defending Nvidia, I'm complaining about nonsensical arguments.
Business_Reindeer910@reddit
so you're saying this isn't a nonsensical or biased argument? :)
Business_Reindeer910@reddit
This is what the current nouveau (in kernel) driver does too for all Turing+ hardware.
pandi85@reddit
Do you remember the flick of linus meme? That's why
pandi85@reddit
As there are so many, know it all responses, here's the source with link to the full talk, for the ones liking to build their own mind on things:
https://www.youtube.com/watch?v=xPh-5P4XH6o
https://www.youtube.com/watch?v=MShbP3OpASA
Brillegeit@reddit
That was about the Tegra CPU intended for automotive use AFAIK, nothing to do with GPUs.
Self driving cars was a huge thing back then and their protocols to stop industrial espionage in that area resulted in a lot of friction with the kernel developers.
BackgroundSky1594@reddit
That's confusing cause and effect. They didn't collaborate before that, before ever being given the finger. Was it a strategically smart thing to insult them on a public conference? Probably not. But they were anywhere from willingly obtuse to actively working against volunteers adding support anyway in those days, so it wasn't completely unwarranted.
w2qw@reddit
Also the situation has actually improved since then and we now have a open source abet out of tree module.
mmmboppe@reddit
if you're ugly and a mirror shows you as tou are, is the mirror insulting you?
Business_Reindeer910@reddit
nvidia is the outlier, not the standard.
Nervous-Cockroach541@reddit
Nvidia drivers are proprietary. I also question if this is just AMD graphics drivers or if it includes chipsets too.
wRAR_@reddit
Yeah, no way to know without calculating it itself or opening the link.
Loudergood@reddit
CPUs even.
MatchingTurret@reddit
Nouveau and nova are both built into the kernel.
HieladoTM@reddit
Open source lincense.
ParaboloidalCrest@reddit
But still, why isn't amd driver, depite the favorable license, a separate package like nvidia's?
chicksculpt@reddit
because of licensing, amd releases its source code under license that is compatible with gplv2, unlike nvidia
Ok-Winner-6589@reddit
Why do AMD GPUs require specific Code on the kernel, but Intel and Nvidia don't?
And why do they require such amount of Code compared to Intel considering that Intel has been around for longer than AMD? What am I missing?
Erchevara@reddit
It's quite easy (adding to other comments):
Nvidia doesn't have their driver in the Linux kernel. It probably has even more lines, but we can never know - well, it was leaked a few times, so we could, actually, and funnily enough, those leaks didn't help, they just provided ammunition for Nvidia to use against open source drivers if they had similar code in the future, and pretty much killed them.
AMD basically has full support for Linux inside the kernel for everything, since forever.
Intel also does the same thing, BUT they only started making dedicated GPUs a few years ago, and I think their previous graphics were streamlined into what is basically 1-2 GPUs per CPU generation. Also, support for Linux with Intel GPUs is sloooow, I have the Arc 140V and the experience on it has been comparable to using Nouveau.
There's also a big gap on the extra tech side. AMD has been basically fully supporting FSR on Linux, while XeSS barely works. It feels like pushing some magic UNLIMITED POWER button on Windows, and a "here's 5 fps with extra blur" on Linux. It's actually likely that we'll get better FSR 4 support than XeSS with Intel GPUs in the future.
TL;DR: Nvidia is closed source, Intel is doing the bare minimum on the GPU side, and AMD is carrying it.
Ok-Winner-6589@reddit
Thanks for the detailed comment
I was thinking a out the integrated GPUs from Intel, but didn't knew they barely release GPUs
Erchevara@reddit
Well, they kinda do now, but they only started recently. Like, I said, previously, they used to have about 1-2 GPUs per generation, but now they do the same (Intel Graphics/Xe Graphics on the lower end), with added integrated Arc GPUs on the higher end for laptops, and dedicated Arc GPUs for desktops.
mrtruthiness@reddit
Intel does have driver code in the kernel. It's about 500K lines of code.
AMD's code is larger because it has a ton of automatically generated header files for hardware register definitions.
NVIDIA's driver is proprietary. The FOSS community driver code (Nouveau) doesn't cover nearly as much functionality and is around 250K lines of code.
Ok-Winner-6589@reddit
Thanks for the info
Loudergood@reddit
Intel absolutely does.
Ok-Winner-6589@reddit
Didn't knew.
Thanks
bubblegumpuma@reddit
amdgpu is supporting like 15 years of AMD hardware. A lot of it is undoubtedly GPU-architecture specific code. Intel's hardware drivers are comparatively narrower - there's been like 3-ish generations of Intel GPU driver with different names within that same timespan. Maybe if you added up all the lines of code in all of the Intel GPU drivers in common usage in the last 15 years it'd be somewhere close to AMDGPU's footprint.
grem75@reddit
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units
The
xedriver supports 12th generation. Thei915driver supports stuff from the 3rd generation in 2004 to 11th in 2019.I don't think combining those two drivers together touches
amdgpuLOC, let alone combined with the legacy AMD drivers.bubblegumpuma@reddit
Isn't there also i965 for the older stuff with some support overlap with i915? Kinda like radeon's small support overlap with amdgpu? It'd only be fair to add in radeon's LoC count if we're including i965 too, though.
Perhaps it is a lot more code, but AMD has a lot of GPU variants, I guess. Intel did coast on essentially the same iGPU architecture for a good few years before they got serious again.
rmyworld@reddit
i965is a Mesa OpenGL driver. It's not a kernel driver, it's a userspace driver that allows applications to talk to the kernel driver via the OpenGL API.I believe it's been replaced by
crocusandirisMesa driver these days.gmes78@reddit
Wrong.
grem75@reddit
That would be in Mesa, not the kernel. It is confusing because there is also an i915 Mesa driver, but it is deprecated along with i965 in favor of the Crocus driver.
Technically there are three Intel drivers, if you include the gma500 one for PowerVR garbage, but I don't think it accounts for much.
I'm not saying AMD's driver size isn't justified, but it isn't because it covers nearly 15 years of chipsets.
dontquestionmyaction@reddit
Nvidia basically doesn't work without third-party mostly closed source modules that are multiple gigabytes in size.
Lars_Fletcher@reddit
Lexus looks alright (aside from hideous word instead of simple badge), others are meh
amarao_san@reddit
They show line counts for assembler, c/c++/make, completely ignoring rust....
deepthought-64@reddit
Rust is in the 9th line in the screenshot in the article.
amarao_san@reddit
I read the original report. https://www.phoronix.com/image-viewer.php?id=2026&image=linux_size_amdgpu_lrg
PerkyPangolin@reddit
It's right there in the screenshot.
fellipec@reddit
6 million lines of code to make the GPU go brrrrrr?
Geeez.
syldrakitty69@reddit
idk how noone has mentioned it but 5 million of those are just machine-generated header files containing definitions for every register in revision of every chip, of which almost none are actually used in the driver.
A lot of them are even just identical head files, with a single number changed across every line.
Scoutron@reddit
It makes sense when you think about it honestly. Unreal Engine 5 contains about as many lines of code as the Linux kernel itself
fellipec@reddit
We went so far from just POKE some bytes into a memory address.
twisted_nematic57@reddit
If you want to see a bit of that history, check out ClosedGL, a software 3D graphics library built to deliver sheer speed on the TI-89/92 graphing calculators https://www.ticalc.org/archives/files/fileinfo/361/36173.html
It's peek and poke all the way down on those old laggards lol
TheG0AT0fAllTime@reddit
I wonder if that's just the line count of the raw files or if it's some kind of clickbait.
I wget'ed and extracted linux-7.0.1.tar.xz then cd'd into it and ran `find drivers/gpu/drm/amd -type f -exec cat {} \; | wc -l` which returned 6049448.
So it's true at least in a raw count of the files but what about newline padding and 1:1 duplicate lines?
Running it through `tr -s '\n' '\n'` shows 5834967 which is very close to the raw value. How about only unique lines? piping it through `uniq` without the newline check gave 6023964
Alright I got nothing. It's really is 6 million lines no clickbait.
sob727@reddit
Is it for AMD CPU + GPU?
Curious how many lines for Intel
Erchevara@reddit
Just the graphics according to the article. Intel probably has a lot more for the CPU, but (at least from my experience) the GPUs are worse than Nvidia atm, but if you're on something like Fedora you get monthly visible improvements at this point, at least on Arc.
Anyway, the code might be entangled and lines are deceiving. Maybe it's just generic Mesa code authored by AMD and that Intel is piggybacking on. Though, to be fair, the gap between Windows and Linux is Intel > Nvidia > AMD. On a modern Arc iGPU (my experience), you can play anything on Windows and barely anything on Linux, Nvidia nowadays works but is not "official", and AMD makes the gap invisible, especially since they're the only ones that have Linux-first gaming hardware.
jashAcharjee@reddit
Linux kernel is mostly drivers written by others. So not a thing to flex, yes monolithic wow great! At the same time tough to maintain.
DeineZehe@reddit
7 whole lines of Fortran holy moly