AMD GPU Linux Driver Becoming "Really Really Big" That It's Starting To Cause Problems

[phoronix]

Phoronix: AMD GPU Linux Driver Becoming "Really Really Big" That It's Starting To Cause Problems

The modern AMD kernel graphics driver "AMDGPU" is the biggest driver within the mainline Linux kernel and is approaching six million lines of code albeit a large chunk of that is made up of auto-generated header files for each supported GPU. But this AMDGPU kernel driver is becoming "really really big" that it's beginning to cause issues for Plymouth that commonly provides the initial boot splash screen experience on modern Linux desktops...

https://www.phoronix.com/news/AMDGPU-Driver-Plymouth-Woes

[V1tol]

Time to split then. As a simple example, into AMDGCN and AMDRDNA parts. There is no reason for older systems to load modern stuff.

[mrg666]

I wonder if the autogenerated header files can be reduced in number and size by eliminating repeated code.

Edit:
I just checked Linux 6.10. The size of drivers/gpu/drm/amd is 582 MB, include directory is taking 428MB of it (73.5%).

[juxuanu]

I have had amdgpu added to my Arch boot init system for a long time and the 2018 laptop doesn't seem to suffer much. I wonder how old those computers he talks about are.

[sbin]

I have had amdgpu added to my Arch boot init system for a long time and the 2018 laptop doesn't seem to suffer much. I wonder how old those computers he talks about are.

There are many people with much older hardware that use Linux thanks to the flexibility and performance that can be achieved on an optimised installation, unlike on some other OSes. It is a valid use case.

[Nille]

Well, i guess they will find a solution for this but i my issue currently is the hardware encoder and the instability of it. i cant use it really on my ryzen 5 5600g and on my steam deck since it caused randomly a system lockup. the steam deck at least just restarts.

[oleid]

Wouldn't Link time optimisation help here?
I can halve the size of a microcontroller based app when using Os+lto compared to O1. Os on its own is a little smaller than O1, but lto really makes a difference here.

[mlau]

I don't get how source size correlates to initialization time. The driver doesn't try to probe all known hw in sequence, it knows which submodules to use based on PCI ID and the ip discovery mechanism on newer asics. I have amdgpu built as module, initialization time is not noticeable at all. Fedora must be doing something else here to get a >3s init delay.

[aviallon]

I don't get how source size correlates to initialization time. The driver doesn't try to probe all known hw in sequence, it knows which submodules to use based on PCI ID and the ip discovery mechanism on newer asics. I have amdgpu built as module, initialization time is not noticeable at all. Fedora must be doing something else here to get a >3s init delay.

Perhaps the time it takes to uncompress the .ko file and load it into memory?

[ptr1337]

Wouldn't Link time optimisation help here?
I can halve the size of a microcontroller based app when using Os+lto compared to O1. Os on its own is a little smaller than O1, but lto really makes a difference here.

At the kernel using Clang (Thin) LTO barely reduces the size at all. GCC's posted LTO implementation for the kernel a while ago showed either no benefits.