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

[ahrs]

Plymouth's fancy splash screens contribute considerably to linux feeling polished or good to the average person, as silly as that might seem

The average linux boot on a system with good hardware (reasonable CPU/GPU and fast PCIe Gen4/5 NVMe drive) probably spends more time in Plymouth than actually booting. Splash screens were great when people had slow hard drives so needed something pretty to look at while the rest of the system caught up. Not so much anymore, a quiet black screen that boots instantly to GDM or SDDM is enough.

[loganj]

Well, technically, headers are definitions on how to call functions in the code. The code is the expanded form of the headers, in a sense.

The real issues seems to be there is a lot of code that isn't used, which is a different concern, for the maintainers and new folks coming to the project.

For example, imagine the Rust folks wanting to interface with the AMD Driver, they would need to read through all of the headers to find which ones to actually use, then make the equivalent to those headers in Rust.

even so, there is no gain in boot time with just move/trim files other than hide them from dev eyes maybe

[NeoMorpheus]

Are we absolutely sure that the AMD code is the only guilty party here?

Maybe Plymouth needs to be adjusted to wait a bit longer?

[cb88]

Or maybe let the AMD devs port to the open source driver the remaining important stuff (if any) not yet present in the open source driver and then remove AMDGPU altogether.

You are confused it seems, AMDGPU IS the open driver. The headers in question are used in part to implement those drivers.֫they are directly machine generated from the hardware source code (Which is why they are so huge and verbose). They document the GPUS in microscopic detail.

Also the drivers these days use the same interfaces for the blob driver as for the open driver... so again nothing to remove or add its all the same stuff.

[agd5f]

Doesn't Intel create a new driver every few generations?

Intel has two drivers (i915 and xe) similar to AMD (radeon and amdgpu). Intel's drivers are smaller because they support fewer GPUs compared to AMD.

Also, splitting out a new driver for different generations of chips is not a panacea either. You end up with a lot of very similar code in both modules that is not easily shared and then you end up needing to fix some bugs in multiple drivers instead of just one.

[deusexmachina]

How much of the AMDGPU driver size is due to managing / interfacing with binary blobs contained within the GPUs?

[dragorth]

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?

Doesn't Intel create a new driver every few generations?

[Danny3]

Why not put them all in a folder instead of putting them in a different repository?
Why are people thinking of moving them in the first place when the problem is after the compilation?

[dragorth]

i'm a bit confuse
are the headers in the final driver after compilation?
i was under the impresion that the headers files are only during compilation
if the are not in the finale driver whats the point in moving/trim them?

Well, technically, headers are definitions on how to call functions in the code. The code is the expanded form of the headers, in a sense.

The real issues seems to be there is a lot of code that isn't used, which is a different concern, for the maintainers and new folks coming to the project.

For example, imagine the Rust folks wanting to interface with the AMD Driver, they would need to read through all of the headers to find which ones to actually use, then make the equivalent to those headers in Rust.

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