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

[oleid]

Are those auto-generated stuff really needed?
Can't they be auto-generated only for the GPUs present in the computer on the fly?
I think AMD should put some work into this!

Then everybody would need to compile their own kernel (That's not really feasible these days) or amdgpu would need to get converted to dkms.

[abiswas]

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.

[Quackdoc]

sounds like it might be time to split it up indeed...

and I know JUST the language to do it in, it would make quite some ad revenue if they did lol

[mmstick]

This is why we need to migrate to a microkernel.

[Ironmask]

This is why I like nvidia's design of putting all the code in the GPU itself and the driver is pretty much a thin wrapper over it. Yes, I know that was just done as a way to bypass licensing stuff, but it's a genuinely novel idea.

Monolithic kernel continues to bear fruit.

While I prefer microkernel designs as well, this has nothing to do with kernel architecture. Linux GPU drivers run in usermode, and this specific problem is because it's taking a long time to load the GPU driver *after* the kernel is loaded and initialized, and the boot screen is waiting for the GPU driver to load.

[user556]

I'd rather wonder how on Earth can header files be responsible for the final object size, much less its initialization time.

Michael doesn't understand systems programming, and apparently y'all don't either.

Michael just said the bulk of the six million lines, which he'd linked, is from the auto-generated headers. But those headers could very much be holding a large amount of config data for the wide swatch of GPUs supported that then all ends up in the compiled binary.

[skeevy420]

While I prefer microkernel designs as well, this has nothing to do with kernel architecture. Linux GPU drivers run in usermode, and this specific problem is because it's taking a long time to load the GPU driver *after* the kernel is loaded and initialized, and the boot screen is waiting for the GPU driver to load.

I think the microkernel suggestions are working on an assumption like each GPU family having their own driver instead of there being one driver to rule them all which would have potentially kept sizes down to prevent an issue like this from even happening. It'd be nice if AMD could do something similar to NVIDIA where the kernel has enough capability to detect the GPU or GPUs installed and then load up vega.ko or kavari.ko or whatever individual drivers are necessary. It's not like I need a driver than can run an R7 260x or a Radeon VII when I have a 6700 XT and a Zen 4 iGPU installed.

[stargeizer]

Hmmm...

The system on where this is reported is an A10-9620P, which is an excavator part, so is quite slow, but certainly not *THAT* slow to produce this on its own. Also, there's a GCN 3rd gen. part on it, so is also, *NOT* that slow, even for today usage...

From the original dmesg log...

[ 1.559363] integrity: Loaded X.509 cert 'Hewlett-Packard Company: HP UEFI Secure Boot 2013 DB key: 1d7cf2c2b92673f69c8ee1ec7063967ab9b62bec'

Well... that died quite fast.

HP bioses/UEFI of the era (2015-2019) were known to be quite buggy and problematic. and "PROBLEMATIC" goes with all caps and luminous lights on the fonts, cartoon style, and that is still an understatement. Maybe is one of these problems that requires bisecting the kernel to know where somebody did something that annoyed these gremlins.

Probably, is not something easy to debug without the having the gremlin (or a similar gremlin with a bugged bios and not so slow processor) , but also not something worth to make the main page of phoronix after all... YMMV IMHO.

[Weasel]

Michael just said the bulk of the six million lines, which he'd linked, is from the auto-generated headers. But those headers could very much be holding a large amount of config data for the wide swatch of GPUs supported that then all ends up in the compiled binary.

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.

[sophisticles]

All these lines of code, their coming in by the millions and millions, no one has ever seen anything like it, and it's a very bad thing. What's happening is a disgrace, it's happening in the boot up process, just look what's happening to computers all around the country with these millions and millions lines of code, it's a disgrace. Just the other day there were reports of all these lines of code eating people's boot splash screens, there's too many lines of code and the system can't handle it, people are being forced to suffer with 3 dots across the screen because all of these millions and millions of lines of code are eating the boot screens and it's a very bad thing, and I will tell you what, this never would have happened if everything wasn't open source.