Mesa To Drop Support For Ancient Drivers

[Vistaus]

But why remove them? I'm sure someone on Phoronix is still using any of these drivers, as always...

[karolherbst]

As long as the HW remains accessible and functional they can kick whatever they want. But before wildly kicking out stuff and cleaning codebases, there should be drivers in place to take over.

you are free to maintain the code if you need it.

[ezst036]

How is the moving target of "ancient" defined here, which chipsets will be affected by this? I looked at the links and sub-links but didnt see this more explicitly defined.(if I missed it, I apologize)

Are we talking ISA Trident TVGA8800s here, or anything up to pre r600? I see some people refer to first gen radeonsi cards as "ancient", so it would be nice to see who gets affected.

[MadeUpName]

How is the moving target of "ancient" defined here, which chipsets will be affected by this? I looked at the links and sub-links but didnt see this more explicitly defined.(if I missed it, I apologize)

Are we talking ISA Trident TVGA8800s here, or anything up to pre r600? I see some people refer to first gen radeonsi cards as "ancient", so it would be nice to see who gets affected.

If your device is running fine with a modern disto installed then it will be fine as the drivers were already removed long ago. If your device is never updated and running a 10 year old distro what do you care?

[nwnk]

How is the moving target of "ancient" defined here, which chipsets will be affected by this? I looked at the links and sub-links but didnt see this more explicitly defined.(if I missed it, I apologize)

It's admittedly a bit difficult to find but the release notes for Mesa 8.0 spell it out:

• Removed all DRI drivers that did not support DRI2. Specifically, i810, mach64, mga, r128, savage, sis, tdfx, and unichrome were removed.

To elaborate a bit:

• i810 means specifically the i810 and i815 chipsets, gen1 in Intel terminology (though that wiki page says i740 was also gen1, which isn't really true, and which we never had any 3D support for anyway)
• mach64 means, well, any ATI Mach64 that was ever supported, which IIRC were only the 3D Rage and Rage Pro chips (wiki thinks the Rage 128 series were in the same generation, which again isn't really true, Rage 128 was more like a Radeon zero-hundred to the original Radeon 7000's R100)
• mga means the Matrox G-series, specifically the G200 G400 G450 and G550
• r128 means the ATI Rage 128 (supra)
• savage means the S3 Savage 3D and Savage 4 chips
• sis means any SiS chip in the SiS 300 range
• tdfx means the 3dfx Voodoos 3 through 5, as a wrapper driver around Glide3
• unichrome means the VIA CLE266 and ProSavage based integrated GPUs

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.

[Zan Lynx]

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.

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.

[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.

[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

[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?pa...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.

[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"?