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

[user1]

Monolithic kernel continues to bear fruit.

So is hybrid kernel. It's difference compared to monolithic is mainly in the internal kernel structure. And microkernels are basically non-existant in general purpose OS'es.

I know that Windows has hybrid shutdown since Windows 8, which speeds up boot time after shutdown. I don't think even MacOS has something like this.

[user1]

Nobody seems to realize that another reason why AMDGPU is so big, is because it currently supports more hardware generation than any other GPU driver, at least in recent history - from the very first GCN from late 2011(!) to the latest RDNA. Compared to that, AMD's Windows driver currently only supports RDNA 1 and newer and it has a separate legacy branch for Polaris and Vega. Older GCN generations are already unsupported for a long time.

[mrg666]

Since the object size came into question, this is the kernel module size of amdgpu
19006993 Sep 15 08:46 amdgpu.ko

I compress my kernel modules with zstd. Then, amdgpu.ko.zst is 3.5MB.

19MB is relatively large but not horrible. My kernel itself is 5.7MB. But this is a compressed and optimized kernel compared to standard kernel that comes with FC40 (12MB).

And, I agree that object size is not 1:1 related to source code size.

[LoneVVolf]

Part of the problem may be that fedora/RH and debian don't seem to compress modules to allow for debug symbols.

An archlinux dev commented that not compressing modules would reduce the package size from 135 to 98 MB, but increase the installed size from 136 to 562 MB .

Decompressing those 562 MB AND writing them may cause issues for a slow system with spinning drives.


It would be interesting to compare plymouth numbers on systems with and without compressed kernel modules.

TL;DR: maybe it's not the size of the kernel that's the problem, but sacrificing performance for better debug possibilities .

[petteyg]

Obvious solution: separate drivers for each model. Stop cooking the entire damn thing into one ginprmous blob to be loaded.

[Danny3]

Are those auto-generated stuff really needed?
Can't they be auto-generated only for the GPUs present in the computer on the fly?
I think AMD should put some work into this!

[marek]

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%).

https://gitlab.freedesktop.org/drm/amd/-/issues/3636

[intelfx]

Where did I say anything about the object size?

Because this is the only interpretation where what you wrote is not totally inconsequential nonsense.

Try to understand what you read before responding to claim you understand other things better.

Right back at you.

[mrg666]

Obvious solution: separate drivers for each model. Stop cooking the entire damn thing into one ginprmous blob to be loaded.

The amdgpu kernel module is a separate file than the kernel itself. And, it is not loaded unless there is hardware detected that needs it.

Actually, there is no problem with AMD driver that I can notice during boot. There is no delay I can notice compared to Intel and Nouveau drivers.

[mrg666]

Are those auto-generated stuff really needed?
Can't they be auto-generated only for the GPUs present in the computer on the fly?
I think AMD should put some work into this!

Those headers are never read during boot after the kernel is built once.