Mesa Developers Discuss Branching Off Old Drivers, Including R300g & i915

[LoneVVolf]

I do have a 10 year old laptop with a r300g card that runs Arch Linux fine with kernel 4.11 , mesa 17 , openbox , gcc 6.3 rtc .

It supports 64-bit (dual amd Turion Xl) and is used atleast 4 days every month .


If mesa wants to clean up old code, I do think the benefit of dropping old software versions would be much bigger then those of dropping old hardware.

[bridgman]

Old software versions ?

[RussianNeuroMancer]

But mesa drivers are always incomplete

Since I mentioned GL4+ I pretty sure that you clearly understand what I mean.

[LoneVVolf]

Old software versions ?

some examples from configure.ac

dnl LLVM versions
LLVM_REQUIRED_GALLIUM=3.3.0
LLVM_REQUIRED_OPENCL=3.6.0
LLVM_REQUIRED_R600=3.9.0
LLVM_REQUIRED_RADEONSI=3.9.0
LLVM_REQUIRED_RADV=3.9.0
LLVM_REQUIRED_SWR=3.9.0

llvm 3.3 was released in june 2013

dnl If we're using GCC, make sure that it is at least version 4.2.0.

gcc 4.2.0 was released in may 2007

# Support silent build rules, requires at least automake-1.11

automake 1.11.1 was released in may 2009

[starshipeleven]

Keep in mind the definitions of the terminology being used. I feel this older, outdated, and neglected hardware should have it's own branch independent of current mesa. So yes, I want it literally dropped from current mesa, but it shouldn't be dropped entirely (in other words, I don't think these drivers should cease to exist). These drivers should still be maintained and should still get some patches from current mesa. Keep in mind many of them are still technically capable of running modern systems comfortably; whether they actually do is a different story, and separating them from current mesa seems to be a good start in fixing that.

I'm not saying things should never be dropped, because I agree that is ridiculous. For example, I was in-favor of the original Pentium being dropped from the Linux kernel, because you could probably go back to the 2.4 kernel and still have all the functionality you need on such a platform.

Reality of life is different, while the hardware might be able to, the driver actually does not, apart from r300 anyway, and there is no manpower working on that because there is lack of testers and bug reports about such hardware. This won't change.

Afaik my old netbook with GMA3150 is laggy as fuck with any DE that requires OpenGL, and considering that you will still have Xorg in distros for at least a decade (that has 2d acceleration for such old hardware) this is more than enough to keep old stuff functional for office use for a reasonable time.

I think that if such people with ancient hardware don't show up in mailing list and start offering some assistence or at least advocating for something, it's fine to drop old drivers. Opensource isn't about pampering freeloaders, but about cooperation.

[RussianNeuroMancer]

Reality of life is different, while the hardware might be able to, the driver actually does not, apart from r300 anyway, and there is no manpower working on that because there is lack of testers and bug reports about such hardware. This won't change.

Afaik my old netbook with GMA3150 is laggy as fuck with any DE that requires OpenGL, and considering that you will still have Xorg in distros for at least a decade (that has 2d acceleration for such old hardware) this is more than enough to keep old stuff functional for office use for a reasonable time.

I think that if such people with ancient hardware don't show up in mailing list and start offering some assistence or at least advocating for something, it's fine to drop old drivers. Opensource isn't about pampering freeloaders, but about cooperation.

For example I do report driver bugs on old hardware. Take a look: https://bugs.freedesktop.org/show_bug.cgi?id=95429
Tell me, is my report help anyone?

[starshipeleven]

For example I do report driver bugs on old hardware. Take a look: https://bugs.freedesktop.org/show_bug.cgi?id=95429
Tell me, is my report help anyone?

You are doing your part, if no developers show up to fix that is another issue. Cooperation requires both sides.

[smitty3268]

some examples from configure.ac

dnl LLVM versions
LLVM_REQUIRED_GALLIUM=3.3.0
LLVM_REQUIRED_OPENCL=3.6.0
LLVM_REQUIRED_R600=3.9.0
LLVM_REQUIRED_RADEONSI=3.9.0
LLVM_REQUIRED_RADV=3.9.0
LLVM_REQUIRED_SWR=3.9.0

llvm 3.3 was released in june 2013

dnl If we're using GCC, make sure that it is at least version 4.2.0.

gcc 4.2.0 was released in may 2007

# Support silent build rules, requires at least automake-1.11

automake 1.11.1 was released in may 2009

Updating those version limitations might save 100 lines of code combined, while dropping a single driver could save 20,000 lines of code.

Guess which one devs are more interested in doing?

Plus, devs can easily test against old versions of software themselves. With old hardware, it's often impossible because you don't have the hardware around to test on and it's hard to get your hands on it even if you wanted to.

Anyway, the GCC version is just a lie - it won't work with 4.2 anyway, that's just a workaround for FreeBSD which has backported various features from newer versions. It ought to be fixed in Mesa and just hardcode GCC 4.6 or BSD for all the checks. And the LLVM 3.3 support is only for llvmpipe/VMWare's purposes, and apparently they are still actively using versions that old in some of their products, so it can't go away just yet.