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

[Luke_Wolf]

Has Plymouth ever worked properly? I've tried it on at least 5 different systems, and on all of them it doesn't start fast enough to cover the initial tty output, so you see ugly text anyway. Then it quits too soon and you see even more tty output before the login manager shows up.

And that's not including the delay to startup it causes. One of the worst projects to exist by far.

The only one I've seen it work at all reliably on is Fedora otherwise has always been hit or miss depending on hardware and an awful lot of missing, not that Fedora is perfect with it either.

[abiswas]

Arch Linux logo, btw.

(fixed ;-))

Arch Linux makes it very easy to create UKIs "BTW" . You can set any boot splash using creating your own bmp. I wish other distros support/switch to it. Also Plymouth should retire imo. It never worked on my PC and always fallback to left top 3 dots and a weird rendering glitch and I have an Intel GPU.

[Paradigm Shifter]

Eh, Plymouth. I've had enough problems with it over the years across a wide range of systems that I'm more inclined to it being the problem. Failing to start, failing to stop, being all messed up with nVidia drivers installed, deciding unilaterally to display on a different monitor to the one everything else displays on (joys of early multimonitor in Linux), hanging when handing off to the display manager (but no hang when Plymouth is disabled)...

[user556]

The size of the headers is completely irrelevant when it comes to loading the driver. You're not compiling shit when loading the kernel and its drivers modules.

Michael wasn't saying they were relevant. He only pointed out that the six million lines, which he'd linked, is mostly headers. Nothing more.

I then added that headers can contain data that ends up in a binary.

[blitz120]

Given that the driver is dynamically loaded, it seems like it would be fairly straightforward to fix. First, begin to create stripped down versions of the driver specific to each GPU chipset, starting with the most commonly used. Do not change the existing AMDGPU driver (yet). Then tweak the loading software to first attempt to load the specific driver; only if it is not found is the AMDGPU. Once these changes are started and the kinks worked out, the code in the original driver can be removed. New GPU chipsets would have only individual drivers written. Eventually, the AMDGPU driver will be obsolete.

[Daktyl198]

Indeed. Sounds like AMD has fucked this up badly. They're either allocating lots of unnecessary structures for different generations of hardware or exposing lots of internal symbols. I fail to see why the driver needs to be any larger than other GPU drivers in the system.

They have significantly more GPU SKUs and features on those GPUs compared to other FOSS drivers. Additionally, they have quite a few generations supported by a single driver these days. The Nvidia FOSS driver is tiny because it barely supports any features on older hardware, and on newer hardware it's just a shim to load a proprietary blob. Intel's GPU support is great but they have less than half the GPU variants that AMD does.

Most of the header for each GPU is probably a giant list of features supported by the driver, and whether or not they're supported by the GPU itself. That being said... it's been a decade since the initial development of the AMDGPU kernel driver and I'm sure a ton of lessons have been learned since then. It may be time to think about rearchitecting the driver for future hardware.

[caligula]

Ok? And you can look at the compiled output.

The size of the headers is completely irrelevant when it comes to loading the driver. You're not compiling shit when loading the kernel and its drivers modules.

Indeed. Sounds like AMD has fucked this up badly. They're either allocating lots of unnecessary structures for different generations of hardware or exposing lots of internal symbols. I fail to see why the driver needs to be any larger than other GPU drivers in the system.

[lem79]

I would suggest switching to UKI splash which I am using. It's static but provides a clean boot logo, in my case which is the "Arch Linux" logo.

Arch Linux logo, btw.

(fixed ;-))

[kiffmet]

Nouveau code base is a fraction of the size and supports 14 years more hardware. Just saying.

And nearly none of it it supports well or even completely.

[kpedersen]

Isn't the module commonly in the initramfs and as such is loaded into a ramdisk by the bootloader before the kernel is run?

Some distros do (firmware as well because there is no easy way to tell if firmware is required, semi-functional modules attach regardless).
Other distros just place disk related modules in initramfs and forgo stuff like plymouth, or render it using efifb.