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

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

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

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?

[deusexmachina]

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

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

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

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

[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

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

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