The AMD graphics driver is reputedly the biggest that mainstream Linux users will encounter, approaching six million lines of code.

That does seem a bit … excessive.

permalink
report
reply
16 points

A decent chunk of that is autogenerated code

permalink
report
parent
reply
5 points

Do they know what it does?

permalink
report
parent
reply
13 points

“Register bit twiddling.” Setting all the modes that all their various cards can operate in, with the associated code for sending the bit updates over the connection bus. Tedious stuff that’s very prone to copy-paste errors if written by hand.

At some point you have to take AMDs word for it that these codes = this functionality, but if the right graphics come out then it can’t be so wrong.

permalink
report
parent
reply
1 point

why?

permalink
report
parent
reply
4 points

On an Intel machine, this makes me want to compile my kernel so much

I should learn how to compile RPM kernels on COPR

permalink
report
parent
reply

Compiling has never been the hard part. The challenge is making it through the entire configuration menu system before succumbing to the urge to gouge your own eyes out with blunt sticks.

Once that’s done, kick off make take a long break; it’ll be compiled by the time you get back to it.

I hear build times are getting longer with the Rust parts, though, so do it soon before you need mainframe access to get a compile within your lifetime.

permalink
report
parent
reply
2 points

The thing is I need to configure, compile, package, sign and then layer, because I am on Fedora Atomic (and because that is the correct way)

And I dont know many of the steps in the middle.

A Github runner for this would be great, like a template where people can choose what kernel they need, which then packages it.

permalink
report
parent
reply
18 points

They should split it in two drivers, one legacy and one all other.

permalink
report
reply
14 points

At least two. Or make it with modules and only load the necessary one.

permalink
report
parent
reply
11 points

Right; any solution they come up with presumably needs to be more scalable than “new drivers” and “old drivers”. Eventually there will be too large a set of “old drivers” and we’ll end up in the same situation with a small “new drivers” driver and a large “old drivers” blob.

permalink
report
parent
reply
6 points

A different driver set for each chip architecture maybe?

permalink
report
parent
reply
12 points

From my understanding, a lot of code in the graphics drivers is special-case handling for specific games to optimize for the way that the game uses the APIs. Is this correct?

In which case it would make sense to have the game-specific code loaded dynamically when that game is launched, since 99.99% of the game specific code will be for games that the user never runs.

permalink
report
reply
6 points

From my understanding 99.999% of those “Game ready drivers” are patches for machines that you do not use but have to download anyway to keep everything on the same version.

permalink
report
parent
reply
3 points

My understanding is that most of that all lives in mesa, and the kernel driver basically just abstracts the hardware.

permalink
report
parent
reply
9 points

How old are those machines?

permalink
report
reply
4 points

Worth noting from the original article

Fedora is working around this in their latest packages by beginning to probe SimpleDRM immediately. Fedora / Red Hat though isn’t the only ones using Plymouth but is largely in use by all major Linux distributions of the past decade. But in recent years the AMDGPU driver has only continued to grow much larger in supporting newer GPUs and tacking on additional features and optimizations.

permalink
report
reply

Linux

!linux@programming.dev

Create post

A community for everything relating to the linux operating system

Also check out !linux_memes@programming.dev

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

Community stats

  • 2.1K

    Monthly active users

  • 710

    Posts

  • 5.9K

    Comments