AMD's Modern Graphics Driver In Linux 5.14 Exceeds 3.3 Million Lines Of Code

[phoronix]

Phoronix: AMD's Modern Graphics Driver In Linux 5.14 Exceeds 3.3 Million Lines Of Code

It was just four years ago the AMDGPU kernel driver was nearly one million lines of code and earlier this year began nearing three million lines. Now with Linux 5.14-rc1 released this week it is at over 3.3 million lines for this kernel graphics driver...

https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-Linux-5.14-rc1-Size

[skeevy420]

Why is this becoming an issue with AMD GPUs now? How come Intel GPUs don't require all the extra code and headers that AMD's seem to need?

[mdedetrich]

Why is this becoming an issue with AMD GPUs now? How come Intel GPUs don't require all the extra code and headers that AMD's seem to need?

Integrated GPU's (within a CPU) tend to be a lot simpler/smaller in scope compared to actual discrete GPU's.

In any case as I have stated elsewhere, this is going to be the new reality so get used to it. If Linux devs are adamant about wanting EVERY driver to be in the tree and not providing a lower level stable ABI (so that drivers can be independent of the Kernel) then yeah, this is the result.

Its not unfathomable that at some time the majority of the code in the Kernel is just going to be graphics drivers, I guess be careful of what you wish for.

[microcode]

Why is this becoming an issue with AMD GPUs now? How come Intel GPUs don't require all the extra code and headers that AMD's seem to need?

As intel's graphics devices gain more features, they'll trend toward the AMD side of the scale.

[tomas]

mdedetrich

If Linux devs are adamant about wanting EVERY driver to be in the tree and not providing a lower level stable ABI (so that drivers can be independent of the Kernel) then yeah, this is the result.

Yes, and that is a good thing!
Kudos to the kernel developers for sticking to their guns and not caving in to this binary stable interface nonsense. We don't need any binary-only blobs for drivers. Nvidia and ARM are the last holdouts. And now Nvidia is at least getting in line and will use the standard in-kernel mechanism DMA-buf for their driver and use GBM for their user-space part. 😊. And more and more ARM GPU drivers are getting the proper Mesa support. Good times ahead.

[microcode]

If Linux devs are adamant about wanting EVERY driver to be in the tree and not providing a lower level stable ABI (so that drivers can be independent of the Kernel) then yeah, this is the result.

Its not unfathomable that at some time the majority of the code in the Kernel is just going to be graphics drivers, I guess be careful of what you wish for.

I don't get why you have to write this like it's some unequivocal bad thing. The Linux driver policy is good, "stable" ABIs are not only a pain to maintain, but a direct source of bloat, and they are not useful if you are willing to build all the drivers from source anyhow. Not to mention, if not for Linux, AMD and Intel most likely would never have published and maintained open source drivers to begin with.

Then on top of all of this, there are all of the secondary benefits. For example, because of the way the Linux driver ecosystem works, you can bring up a new CPU architecture and have working graphics, wireless, ethernet, and USB drivers with little or no porting effort, and without having to run drivers in a DBT or something lol.

Having millions of lines of header files in the kernel is a sign that things are going well, on the scale of things where you should "be careful what you wish for", the consequences of this wish are almost all positive, and the negative consequences are almost all minor. Just having these headers sitting around in the kernel tree costs almost nothing, and is useful.

Now, granted, AMD could probably stand to simplify their hardware a little bit, or call for more industry-wide standardization in host software interfaces for configuring display outputs (a huge portion of the headers are for this), but there are limits.

[Slartifartblast]

That's a lot of unwanted baggage if you don't have/want or use an AMD GPU.

[tomas]

microcode

The Linux driver policy is good, "stable" ABIs are not only a pain to maintain, but a direct source of bloat...

Spot on. The open source graphics driver stacks on Linux are able to share a LOT of common code, both in Mesa and in the kernel parts. Compare this to Windows where every driver stack is completely separated from each other, like vertical silos, duplicating enormous amount of functionality, especially in the user space part. Now, I might be wrong, but I can't imagine that the Intel graphics driver stack (kernel driver parts and the Open GL/Vulkan /DirectX parta) shares a single line of code with the corresponding AMD graphics stack on Windows? So if a fix is done to the Intel stack affecting for example DirectX in a generic way, it will not benefit the corresponding AMD part, and viceversa.

[Alexmitter]

That's a lot of unwanted baggage if you don't have/want or use an AMD GPU.

I hope you know that things like amdgpu reside not in the kernel but as a loadable binary called kernel object, .ko files are only loaded when the kernel detects certain hardware.
If you do not run a amd gpu, you will not run this code, similar as you do not run the i915 driver if you have a amd gpu.

[Alexmitter]

People need to always keep in mind that most of AMDGPU is automatic generated human readable header files with the registers for each supported GPU. The rest of the code, code that actually does something is highly shared between all the different GPU generations supported.

And if you do not have a amd gpu, then you will not even have the resulting binary code running as it resides in a loadable kernel object only loaded at boot if it detects a amd gpu.