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

[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.

[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

[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!

[petteyg]

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

[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 .

[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.

[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.

[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.

[_r00t-]

The amdgpu driver is one the biggest project ever in the Linux Kernel regarding the amount of lines of code it has. I don't want to be ungrateful and I would like to thank the amdgpu developers for their work, but some parts probably needs to get rework. The issue with plymouth is just a minor issue compared to the gpu lockup with ring timeouts. I have this issue at least for 4 years, sometimes rarely, sometimes often. I hope this will be solved in Linux Kernel 6.12 as is mentioned here.

[mrg666]

I'd rather wonder how on Earth can header files be responsible for the final object size, much less its initialization time.

Michael doesn't understand systems programming, and apparently y'all don't either.

Where did I say anything about the object size? Try to understand what you read before responding to claim you understand other things better.