Mesa To Drop Support For Ancient Drivers

[oiaohm]

i wasn't proposing not removing this ancient drivers(i'm aware of their problems) but split whatever was left after into legacy(non-gallium drivers, mesa ir, unused state trackers, tls, etc.) and master(vulkan, gallium active state trackers, nir, gallium drivers).

Sorry if it wasn't clear

Unfortunately legacy(non-gallium drivers, mesa ir, unused state trackers, tls, etc.) majority of this is the stuff that due to kernel changes does not work any more and that Linux and BSD based solutions are not shipping any more so are in a very poor state at best to don't work any more at worst.

Gallium3D starts 2008 and gets broad adoption in Mesa by 2011 with 10 different drivers covering a lots of hardware. Those have been maintained right up to current day. These drivers in places support back to to fairly old cards like the old ATI R100 series from the year 2000 is support by the current AMD Gallium based drivers. This is the hard reality almost everything in the legacy list has not been in production for at last 10 years with the majority has not been in production for at least 20 years.

What you say is master(vulkan, gallium active state trackers, nir, gallium drivers) happens to cover a very large time frame thinking this is starting with cards that were made in the year 2000.

Other hard reality there has been 10 years for people to decide their hardware was important and migrate the driver to Galluim3d to ease maintenance. DRI2 is from 2008 as well. So there has been over 10 years to migrate from DRI1 to DRI2/3.

Realities are hard like Windows 10 the oldest drivers that can be installed in that are Windows 7 drivers. For everyone there is roughy 10 year old hard wall for driver support. As in if the driver has not been updated to current day standards at some point in the last 10 years it ceases being usable mostly due to security design fault being fixed.

jrch2k8 you were not thinking how old the stuff you were putting in the legacy pile is. What you were putting in the legacy pile is fairly to the point it need to go away. If any of that hardware is used enough or is still made somewhere new drivers made.

Yes some people are going to complain that there bit of hardware is no longer supported as the legacy stuff goes away but its not really been properly supported for 10 years. Maybe this will be a wake up call to some people that drivers of the hardware your are using you will be wanting getting on going maintenance.

https://www.phoronix.com/scan.php?page=news_item&px=OTg0Mg

By the way this is the second announcement. The first announcement was in 2011 when the drivers they are dropping now they moved out of mainline Mesa. Yes 2011 they did the split between legacy and master we are now 9 years past that point.

[duby229]

I am pretty sure that there were some 64-bit Xeons delivered on boards using an ATI R128 (or something similar) as the integrated GPU.

They definitely did, although it wasn't integrated, all those server boards with rage128 had a separate GPU soldered to the board.

[jrch2k8]

Seams like a idea until you wake up /dev/mem and other kernel features a lot of these non KMS drivers depend on is also getting more and more restricted so even having a Mesa legacy branch does not mean it will work on newer kernels. In fact due to the security flaws UMS(user mode setting) requires open in the kernel these have to go away.

Horrible as it sounds there comes a point where either you make new drivers or drop the hardware support and that is where we are right now.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-Matrox-G200

The old Matrox mga stuff(G200 G400 G450 and G550) is being part with new driver for Matrox G200 desktop card. Yes this is a KMS driver so none of the historic security flaws and none of needing features that have to be removed for security reasons.

So some bits of hardware are having new drivers written others are not.

i wasn't proposing not removing this ancient drivers(i'm aware of their problems) but split whatever was left after into legacy(non-gallium drivers, mesa ir, unused state trackers, tls, etc.) and master(vulkan, gallium active state trackers, nir, gallium drivers).

Sorry if it wasn't clear

[andre30correia]

old stuff who nobody uses, it's a good decision do remove them, people who need them can build old mesa to use them the documentation is there,but I doubt such hardware will work in new software

[oiaohm]

To be fair, I don't think anyone's stopping community members from stepping up and rewriting these drivers so that there's a KMS kernel driver and DRI2 Mesa driver.

Lot of documentation and test-suite being added to the Linux kernel to help those wanting to make a new KMS driver. So the welcome mat is being rolled out for anyone who wants to and can step up.

It might be even merged if it's in maintainable state. But it's realistic to say that will not happen. The porting effort at this point would probably take insane amounts of time to even get to a "buggy but kinda works" state for this large amount of drivers.

Problem is a lot harder. Matrix G200 has been quite simple todo. As wacky as it sounds its possible to get something functionally the same as a Matrix G200 new from parties who license to be able to produce G200 compatible in their products.

Lot of those old legacy drivers you cannot buy new versions of the cards any more by any means this is a problem. Lets say you are the mesa3d project and want to set up a test system to test the function of a driver patch you are now depending on old cards that could have came defective. So when a test fails is the patch defective or is the card you tested against defective. The old existing DRI1 and before drivers are already in "buggy but kinda works" camp and getting buggier.

If you have not worked out can step up its the cards to test with. Old card that lightly being used may have many more years in it with normal usage but if you put it in a build server running tests 24/7 it can be lucky to last a week. New card you will have at least 2 year of abuse testing out patches before the thing dies. The people who can step up to make new drivers for these really old GPU that are no longer in production anywhere will need a huge stockpile of them. Worst case needing all the functional versions of that GPU left in existance to write a new driver in that case would be pure stupidity as you basically made sure there were no possible end users by making the driver because in the process you killed all the cards.

This is a true rock and hard place problem.

Quite a few of the DRI1 and before drivers will make pure sense just to drop them off the supported hardware list for at least one following reasons.
1) There is not enough of them left to even maintain their current driver in perfectly functional state let alone write a new driver.
2) The hardware even when new was super glitchly(this is not driver trouble) . So bad hardware this makes creating functional drivers really hard because you have mountains of quirks this is S3 family of cards..
3) There is none of them left. There are a list of GPU that were manufactured in the time frame of the defective caps mess with defective caps in the power rails and poor GPU got like 12 volts in on low voltage rail and died. Yes there were quite a few of those in the legacy part of the mesa drivers where there are simple zero of the cards left due to major design defect from new making sure they are all dead or will be dead as soon as someone applies power.

About 90 percent of what has been said to be dropped falls under one of those 3 points.

[nanonyme]

Seams like a idea until you wake up /dev/mem and other kernel features a lot of these non KMS drivers depend on is also getting more and more restricted so even having a Mesa legacy branch does not mean it will work on newer kernels. In fact due to the security flaws UMS(user mode setting) requires open in the kernel these have to go away.

To be fair, I don't think anyone's stopping community members from stepping up and rewriting these drivers so that there's a KMS kernel driver and DRI2 Mesa driver. It might be even merged if it's in maintainable state. But it's realistic to say that will not happen. The porting effort at this point would probably take insane amounts of time to even get to a "buggy but kinda works" state for this large amount of drivers.

[nanonyme]

None of these have KMS support, none of them support anything newer than DirectX 7 / OpenGL 1.3ish, and except for the Matrox G550 none of them exist in PCIE versions. I don't think any of the integrated chips in this list were ever attached to a 64-bit CPU. And again, Mesa hasn't actually included any of these drivers since 2012, so this is just removing the ability to load drivers you're already not building.

Isn't saying "DRI1 driver" synonym to saying "no KMS support"?

[oiaohm]

You guys should seriously consider to simply split mesa into legacy and Current and probably is a nice time to do so as well, i mean:

1.) Activity on non-gallium drivers is almost nill this days and they all are for discontinued hardware at this point. Legacy.
2.) Many state trackers are non functional or relevant this days, like XA, XVMC, etc. Legacy.
3.) Mesa IR, i don't think if you do 1 and 2 have any use anymore. Legacy.
4.) So on and so forth.

you get my point, just keep that branch for fixes only and add proper libglvnd support(aka avoid collisions with current mesa) to avoid conflicts and at the same time you get a smaller leaner Mesa for vulkan and current Gallium drivers, is a win - win.

Caveat: this won't remove support for your hardware, if you have an DRI card/IGP simply install mesa-legacy and voila and it will be better for you since it means minimal chance of something else breaking your drivers

Seams like a idea until you wake up /dev/mem and other kernel features a lot of these non KMS drivers depend on is also getting more and more restricted so even having a Mesa legacy branch does not mean it will work on newer kernels. In fact due to the security flaws UMS(user mode setting) requires open in the kernel these have to go away.

Horrible as it sounds there comes a point where either you make new drivers or drop the hardware support and that is where we are right now.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-Matrox-G200

The old Matrox mga stuff(G200 G400 G450 and G550) is being part with new driver for Matrox G200 desktop card. Yes this is a KMS driver so none of the historic security flaws and none of needing features that have to be removed for security reasons.

So some bits of hardware are having new drivers written others are not.

[jrch2k8]

Not likely. RN50 was the server chip and it was radeon based.

You guys should seriously consider to simply split mesa into legacy and Current and probably is a nice time to do so as well, i mean:

1.) Activity on non-gallium drivers is almost nill this days and they all are for discontinued hardware at this point. Legacy.
2.) Many state trackers are non functional or relevant this days, like XA, XVMC, etc. Legacy.
3.) Mesa IR, i don't think if you do 1 and 2 have any use anymore. Legacy.
4.) So on and so forth.

you get my point, just keep that branch for fixes only and add proper libglvnd support(aka avoid collisions with current mesa) to avoid conflicts and at the same time you get a smaller leaner Mesa for vulkan and current Gallium drivers, is a win - win.

Caveat: this won't remove support for your hardware, if you have an DRI card/IGP simply install mesa-legacy and voila and it will be better for you since it means minimal chance of something else breaking your drivers

[agd5f]

I am pretty sure that there were some 64-bit Xeons delivered on boards using an ATI R128 (or something similar) as the integrated GPU.

Not likely. RN50 was the server chip and it was radeon based.