Linux 5.14 GPU Driver Updates Come In Heavy With ~300k New Lines Of Code

[phoronix]

Phoronix: Linux 5.14 GPU Driver Updates Come In Heavy With ~300k New Lines Of Code

The Direct Rendering Manager (kernel graphics/display driver) updates for Linux 5.14 are putting on the pounds with nearly 300k lines of new code added (312,187 insertions, 22,367 deletions). The big increase is driven by new AMD Radeon graphics support added, a new Microsoft driver added, and other changes...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-DRM-Drivers

[rene]

Let me guess, 300k lines of mostly duplicate, auto generated header defines and code? And people applaud the removal of 3k lines for nice vintage hardware, like early 32-bit sparc, early PowerPC, or the original i386, ... but 300k lines are no maintainenance burden, ... ;-)

[cl333r]

Let me guess, 300k lines of mostly duplicate, auto generated header defines and code? And people applaud the removal of 3k lines

I was thinking the same, rather than dumping 5 figures of autogenerated LOCs isn't there a more compact way of expressing all that repetitive stuff?

[Zan Lynx]

I was thinking the same, rather than dumping 5 figures of autogenerated LOCs isn't there a more compact way of expressing all that repetitive stuff?

Sure. Binary blobs with no source at all.

[mdedetrich]

Sure. Binary blobs with no source at all.

Or instead of mandating that every single driver sit in the Kernel tree, maintain a low level stable graphics ABI/API. Drivers can still be open source, they just don't need to sit in the Kernel tree (and as an added bonus you can update graphics drivers independently from Linux kernel versions unless they break said API/ABI).

At this rate, I don't see it absurd that some point in the future the Kernel will be like 70%+ graphics drivers. Graphics drivers are not typical drivers

• They are massive, especially in terms of scope (they are basically turning into a different type of CPU over time)
• They change frequently with the features they provide
• Newly released software (i.e. AAA games) expect these new features to be available when game launches. Linux will never be a tier1 gaming platform with the current setup of how Linux works with drivers.

There is a massive difference between a keyboard driver which remain virtually unchanged over 30 years and graphics drivers and we should treat it that

NOTE: It makes sense for basic graphics drivers that can pull up a display to be in the tree so you get video output on boot, but the full featured graphics drivers should be maintained outside of the Linux Kernel.

[NobodyXu]

Or instead of mandating that every single driver sit in the Kernel tree, maintain a low level stable graphics ABI/API. Drivers can still be open source, they just don't need to sit in the Kernel tree (and as an added bonus you can update graphics drivers independently from Linux kernel versions unless they break said API/ABI).

At this rate, I don't see it absurd that some point in the future the Kernel will be like 70%+ graphics drivers. Graphics drivers are not typical drivers

• They are massive, especially in terms of scope (they are basically turning into a different type of CPU over time)
• They change frequently with the features they provide
• Newly released software (i.e. AAA games) expect these new features to be available when game launches. Linux will never be a tier1 gaming platform with the current setup of how Linux works with drivers.

There is a massive difference between a keyboard driver which remain virtually unchanged over 30 years and graphics drivers and we should treat it that

NOTE: It makes sense for basic graphics drivers that can pull up a display to be in the tree so you get video output on boot, but the full featured graphics drivers should be maintained outside of the Linux Kernel.

Linux kernel has explicitly stated that they want the API/ABI to be unstable so that they can make improvements any moment they want, freely, instead of maintaining backwards compatibility.

So if you want an out-of-tree driver, you need to build it as a module, which you also have to modify form time to time for new release.

[middy]

Or instead of mandating that every single driver sit in the Kernel tree, maintain a low level stable graphics ABI/API. Drivers can still be open source, they just don't need to sit in the Kernel tree (and as an added bonus you can update graphics drivers independently from Linux kernel versions unless they break said API/ABI).

At this rate, I don't see it absurd that some point in the future the Kernel will be like 70%+ graphics drivers. Graphics drivers are not typical drivers

• They are massive, especially in terms of scope (they are basically turning into a different type of CPU over time)
• They change frequently with the features they provide
• Newly released software (i.e. AAA games) expect these new features to be available when game launches. Linux will never be a tier1 gaming platform with the current setup of how Linux works with drivers.

There is a massive difference between a keyboard driver which remain virtually unchanged over 30 years and graphics drivers and we should treat it that

NOTE: It makes sense for basic graphics drivers that can pull up a display to be in the tree so you get video output on boot, but the full featured graphics drivers should be maintained outside of the Linux Kernel.

i like how the drivers are built in. its nice not worrying about having to install drivers.

[mdedetrich]

Linux kernel has explicitly stated that they want the API/ABI to be unstable so that they can make improvements any moment they want, freely, instead of maintaining backwards compatibility.

So if you want an out-of-tree driver, you need to build it as a module, which you also have to modify form time to time for new release.

I know thats the position of the Linux kernel devs. If they don't change it then they have to deal with the consequences of which there are many.

Also maintaining a stable ABI isn't hard if its correctly designed, Microsoft has been doing it since the Vista days and by all accounts and measures their graphics stack is lightyears ahead of Linux

i like how the drivers are built in. its nice not worrying about having to install drivers.

As I said before, you would still have a basic graphics driver in tree (Windows also has one) and since Linux distro's have great package management, installing graphics drivers is much easier than Windows anyways.

I mean have a look at the latest hardware linux survery posted at https://github.com/linuxhw/HWInfo. 13% of Linux users experience hardware issues due to running older Linux kernels and graphics drivers are the most extreme examples of drivers which change significantly between Kernel releases (both in terms of bug fixes and in terms of features).

If you for example have a recent AMD graphics card, the difference between Kernel 5.10/5.11/5.12/5.13 is staggering. Manjaro for example only has 5.10 as LTS release, which means you are also kinda screwed using that Kernel if you have a newer graphics card and you are sticking to LTS (for obvious reasons).

[NobodyXu]

I know thats the position of the Linux kernel devs. If they don't change it then they have to deal with the consequences of which there are many.

Also maintaining a stable ABI isn't hard if its correctly designed, Microsoft has been doing it since the Vista days and by all accounts and measures their graphics stack is lightyears ahead of Linux



As I said before, you would still have a basic graphics driver in tree (Windows also has one) and since Linux distro's have great package management, installing graphics drivers is much easier than Windows anyways.

I mean have a look at the latest hardware linux survery posted at https://github.com/linuxhw/HWInfo. 13% of Linux users experience hardware issues due to running older Linux kernels and graphics drivers are the most extreme examples of drivers which change significantly between Kernel releases (both in terms of bug fixes and in terms of features).

If you for example have a recent AMD graphics card, the difference between Kernel 5.10/5.11/5.12/5.13 is staggering. Manjaro for example only has 5.10 as LTS release, which means you are also kinda screwed using that Kernel if you have a newer graphics card and you are sticking to LTS (for obvious reasons).

Last time I heard is that the old API/ABI in windows has already become a serious problem.

Some said they even maintain win xp or win98 kernel API/ABI, which adds a lot of bloat and requires tons of care when writing the new OS.

Perhaps this is why win 10 updates are so unstable and unusable given the amount of resource Microsoft throws at — maintaining old, obsolete API/ABI that is seldom used is a pain and makes the kernel more fragile.

Also, it is note worthy that the module API/ABI of the kernel is somewhat stable.

Nvidia has been doing it all the time.

The reason why intel and amd is upstreaming their driver instead of maintaining a separate open source repository is that the kernel contributors will help review the code, points out the error and updates the use of APIs when they get changed.

Even if they are put into different repository, they will still need to be reviewed by kenrel contributors anyway.

[mdedetrich]

Last time I heard is that the old API/ABI in windows has already become a serious problem.

Some said they even maintain win xp or win98 kernel API/ABI, which adds a lot of bloat and requires tons of care when writing the new OS.

Perhaps this is why win 10 updates are so unstable and unusable given the amount of resource Microsoft throws at — maintaining old, obsolete API/ABI that is seldom used is a pain and makes the kernel more fragile.

This doesn't have anything to do with what you are talking about, you are just spurting random stuff here.

Also, it is note worthy that the module API/ABI of the kernel is somewhat stable.

Nvidia has been doing it all the time.

Not entirely true and stated in a misleading way. NVidia has a wrapper over the DKMS kernel driver which they do have to update somewhat frequently, so the ABI/API itself is not that stable (and its not even advertised as such)

The reason why intel and amd is upstreaming their driver instead of maintaining a separate open source repository is that the kernel contributors will help review the code, points out the error and updates the use of APIs when they get changed.

Which again has nothing to do with the problems being talked about. This also is not a good thing because it means that bugs/fixes are blocked by a bureaucratic Linux process, which wouldn't be an issue if we had distributions running older stable Kernel versions.

Even if they are put into different repository, they will still need to be reviewed by kenrel contributors anyway.

Well no they don't, and thats the point. They are responsible for writing the driver, just as AMD/NVidia are on Windows. If there are bugs/issues, they work on it themselves and push the fixes/changes