Proposal Raised For Dropping Mesa's Classic OpenGL Drivers From Mainline This Year

[phoronix]

Phoronix: Proposal Raised For Dropping Mesa's Classic OpenGL Drivers From Mainline This Year

It's been proposed in the past but never acted upon yet but the idea of dropping/retiring Mesa's "classic" OpenGL drivers from the mainline code-base and letting them potentially live on in an "LTS" branch has once again been brought up...

https://www.phoronix.com/scan.php?pa...a-Classic-Main

[StarterX4]

Just drop them all except i915 – there are a lot of notebooks based on Atom/BayTrail nowadays.

[9Strike]

Good. Distribution should pick it up as an additional package for older hardware, but let's focus on "new" (aka non-ancient) hardware.

[MadeUpName]

My 4 year old HTPC is based on a Celeron N3160 with i915. I will be happy to move on if AMD ever gets off their asses and releases Van Gough.

[iskra32]

I would definitely like them to not drop support for i915. Either keep it or port sandy bridge-haswell to gallium, because a lot of people, myself included, still use that hardware.

[oiaohm]

Just drop them all except i915 – there are a lot of notebooks based on Atom/BayTrail nowadays.

You should have read the mailing list post.
https://lists.freedesktop.org/archiv...ch/224984.html

I konw there is some interest in getting i915g in good enough shape that it could replace i915c, at least for the common case. I also am aware that Dave, Ilia, and Eric (with some pointers from Ken) have been working on a gallium driver to replace i965. Neither of those things are ready yet, but I've taken them into account.

There are two i915 drivers. i915c that is the classic most people use. And the i915g that is gallium driver that is the modern one that under development. So its possible to get rid of the classic drivers and keep i915 support if enough resources are put into the i915g driver. Please note some of those resources will be people with i915 hardware testing the i915g driver on a volunteer base. There is a horrible one the are particular bits of Intel silicon that the Intel CI solution does not have yes there are different i915 with know quirks that i915g driver developers currently cannot test if their driver in fact works with.

[oiaohm]

Good. Distribution should pick it up as an additional package for older hardware, but let's focus on "new" (aka non-ancient) hardware.

9Strike there is another problem here. Ancient hardware you run into the problem that it does not matter if it the mesa developers or distributions you can run into the problem of lack of hardware to test against.

So splitting the old drivers where there is a lack of hardware to test with from the modern does make sense.

[Leopard]

Crocus is under development as a Gallium driver for gpu's that will be affected from that mentioned removal.

https://gitlab.freedesktop.org/airli...rocus_todo.txt

[NateHubbard]

9Strike there is another problem here. Ancient hardware you run into the problem that it does not matter if it the mesa developers or distributions you can run into the problem of lack of hardware to test against.

So splitting the old drivers where there is a lack of hardware to test with from the modern does make sense.

I feel like I'm having a parsing error while reading this.

[oiaohm]

I feel like I'm having a parsing error while reading this.

Think I might have been too short.

CI. Continuous Integration testing. This is something different distributions and mesa developers like todo. This form of testing is not that hardware friendly. Lets say you are running mesa testsuite and the OpenGL and OpenGL ES Conformance Tests to make sure everything it working right every so many commits/changes. This means you are running the hardware at max load over and over again. This does shorten the hardware life span.

When the hardware is no longer been made new you cannot go out and just buy new. This results even with Intel own CI they don't have particular bits of hardware now that CI use to have because they have worn out their stock pile of that part due to the CI process max loading the parts over and over again.

Now lets think though the problem for 1 min. Maybe you don't want to push old hardware drivers out to distributions for CI. As this means each distribution could end up fighting over the limited supplies of that hardware. Also you want to reduce the CI triggers on the older drivers so the older hardware does not have to run as many CI passes.

It sounds simple idea lets just push the maintainer-ship to distributions. But the upstream Mesa reason to split the old drivers from the new is the new its simpler to get hardware to test with and having old in its own branch will result in less CI triggers so longer life span out the hard to replace test equipment.

Since the old its hard to get hardware to test with pushing the testing/maintainer-ship out to distributions may be a really bad move as there is the classic supply/demand problems here.