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

[Blisterexe]

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.

A lot of people have older pc's, so i think the extra quarter second added to the boots of people with fast pc's is worth it.

[coder]

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?

Yeah, I had in mind a process (and supporting tools) that's mostly automated.

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

Performance-wise, it wouldn't be a game-changer. IIRC, we've seen code layout optimizations worth <= ~10%. However, I'll bet you could reduce the compiled size by a lot more than that.

[ET3D]

Like many others here, I wondered what the code size has to do with the boot problem, and it seems that it's not directly related. From the Plymouth issue discussion:

I believe the most time is actually spend on dynamically linking the ko after it has been decompressed / loaded into mem. That approx. 16MB of code is likely calling kernel functions like dev_dbg() / dev_info(), etc. in a lot of places and all those call sites need to be dynamically patched with the function address of those symbols. At least that is what I think is causing the biggest slowdown.

[grigi]

There are at least 2 separate classes issues they need to address to fix the issue of the driver being big and slow to load.
1. Janitorial work so that it's easier to work on it (this is an example)
2. Performance fixes, so that the driver can load faster

You need to do both types of cleanup. That's just how maintenance programming works.

[intelfx]

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

I’m quite far from an average person and I love Plymouth on my machines quite much, so…

[nerdistmonk]

Why not fix plymouth instead of screwing with critical infrastructure? I personally have never seen plymouth work on any machine that had it, it breaks because of -everything-, especially if you use nvidia.

(bites tongue to avoid epic rant about how nonsensical the decision making process is in the linux community now)

[jsbiff]

I have to say, I'm not a big fan of moving the AMDGPU headers into a separate repository. Pruning the the headers and eliminating the unused bits seems to me as a much more sane solution to this problem.

Of course an even better solution would be to not store generated code in the kernel tree at all, and store the program that generates that source in stead, though that might prove difficult in the case of AMDGPU. I am not sure if that program/those programs are publicly available.

From my reading of the article, even though the headers aren't used by the driver, some of them are used by other projects, like Mesa. It sounds like if you delete them totally, you break Mesa and maybe some other stuff?

[muncrief]

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?

I wondered about that when reading the initial article NeoMorpheus. It's only a few seconds and surely changing the Plymouth timeout is the most simple and direct way of fixing the immediate "problem."

In any case I have no objection to restructuring and optimizing the code size, but as many others on this thread have so eloquently expressed it's unlikely to be an easy task, and given the effort required care should be taken so that the changes address the issues of today, and the future, to as great a degree possible. And that will require time and input from many architects and engineers and users.

[ReaperX7]

They should move documentation in headers to document files. Reference them as in the header, but leave the documentation out.

Also, split amdgpu-gcn and amdgpu-rdna into their own driver branches.

We don't need yet another bloated repo going up.

[agd5f]

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.

There are separate headers for function definitions and the files are stored in different places in the source tree.

The register headers just define the offsets and masks for registers and so that the code is readable. E.g.,

WREG32(mmMY_REGISTER, ENABLE_FEATURE_MASK);
vs.
WREG32(0x8800, (1 << 3));

The former is a lot more readable and less error prone than the latter.