Idea Raised For Reducing The Size Of The AMDGPU Driver With Its Massive Header Files

[NateHubbard]

linux ... average person

Oh, sure.
Personally, I like seeing the kernel load for all of like 3 seconds.

[superm1]

The headers themselves don't affect the size of the binary. They're just hardware documentation within the source tree that is used by some of the driver.

This is tangential to the issue raised. I feel that to decrease the driver size there would need to be some efforts to find and root out code duplication.

[avis]

<offtopic>

Michael

I think this comment could be very interesting for Linux users/Phoronix readers:

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/703#issuecomment-2353494545

</offtopic>

[schmidtbag]

I'd say start with the python script to remove the unused headers. If that still doesn't appear to be enough, then maybe consider a repo.

[superm1]

I'd say start with the python script to remove the unused headers. If that still doesn't appear to be enough, then maybe consider a repo.

A major problem with this approach is that when there is a need to reference a register after they were first introduced that you don't have the definition and need to manually re-introduce it. This happens all the time when bugs are found, and some register values need tuning.

[varikonniemi]

this is not a solution to the load time, but to the kernel source size. I cannot see why loading few mb of driver at boot would be something that takes so long plymouth times out.

whatever the issue turns out to be, it could have been prevented by a nicely integrated kernel boot splash. Along with other issues/complications the plymouth way of doing things causes.

[kiffmet]

All that because a Pentium 4 is too slow loading the drivers for a 6800XT during boot and broke the eyecandy boot animation…

Seriously folks?!

[superm1]

this is not a solution to the load time, but to the kernel source size. I cannot see why loading few mb of driver at boot would be something that takes so long plymouth times out.

whatever the issue turns out to be, it could have been prevented by a nicely integrated kernel boot splash. Along with other issues/complications the plymouth way of doing things causes.

This is one possible theory: 219229 – significant delays when secureboot is enabled after 6.10 kernel

[ezst036]

Is it expected that the Nvidia open source driver will have this same header size problem once we get 10-15 generations in?

How does the Intel driver handle the problem for the integrated video?

[Vorpal]

What about some way to selectively determine what can be compiled with -Os ? By compiling some parts of the driver that way, you might even achieve faster runtimes! This wouldn't only be applicable to AMD's GPU driver, either.

Sure, you can use GCC/Clang attributes to change compilation flags (including optimisation level) per function. This would be quite a manual process and a massive amount of work. What would be more viable is using PGO (Profile Guided Optimisation) to record representative workloads, and use that to determine what parts are hot or not. I don't know off the top of my head exactly how that ties into optimisations levels (if at all) or if it is only about things like improving inlining/outlining. But that seems like a feasible thing to add in compilers if it isn't already supported.

The next question would then be how to distribute pre-made PGO profiles for a given source release, and that may be where this idea breaks down. Perhaps you could pull data back from PGO and use that to automatically annotate functions as hot or cold in the source though?

Still I doubt this would make such a big difference that it would be relevant here.