Mesa Considers Dropping Default Support For 16+ Year Old x86 CPUs
The Mesa graphics stack supports a really wide range of hardware. The current stable 21.0 Mesa version works on really old 32-bit x86 computers with ancient graphics cards. By-default support for some of those old x86 computers could soon be a thing of the past, the Mesa developers are currently discussing if the SSE2 processor instructions should be a default compiler flag for Mesa builds. GNU/Linux distributions will still be able to set their own flags.
written by 윤채경 (Yoon Chae-kyung) 2021-03-28 - last edited 2021-03-31. © CC BY
The AMD Athlon XP 3000+ (AXDA30000DKV4D) CPU, seen here on a ASUS A7V8X-LA motherboard, may soon become one of several ancient computer processors without official by-default Mesa support.
The American Intel corporation introduced the Streaming SIMD Extensions 2 (SSE2) instruction set when they launched the Pentium 4 in 2000. It was later expanded into SSE3, with 13 additional instructions, in 2004, and it was further expanded to SSE4, with 47 additional instructions, in 2006.
Current versions of the Mesa can be used on ancient computers without the SSE2 instruction set and the graphics hardware on those machines is also mostly supported. The Mesa developers are considering moving the older "classic" graphics drivers out of Mesa to a special "classic-lts" branch. They are, in that same spirit of raising the bar for what hardware should be officially supported, now considering making the SSE2 instruction set a by-default requirement to compile and use Mesa. That proposal is being discussed as "Mesa issue 9868: Default enable SSE2 on mesa builds. Only post 21.1 release".
Who Gets Hurt?[edit]
The downside of making the SSE2 compiler flag a Mesa default is simple: Builds using default compiler flags can no longer be used on hardware without SSE2. The hardware in question is, concretely:
- 32-bit AMD Athlon processors prior to Athlon 64 (launched in September, 2003)
- 32-bit Intel processors prior to Netburst (launched in November, 2000)
- 32-bit Via processors prior to C5 aka Nehemiah (launched in 2005)
- Some special-purpose 32-bit x86 embedded boards like the Intel Quark (launched in 2013)
How much this downside actually matters in this day and age is a good question.
There are not that many GNU/Linux distributions that still support 32-bit x86 processors at all these days, most of them require a 64-bit x86-64 processor. A few have even dropped support for running older 32-bit applications while most of distributions do support 32-bit programs with i386/i686 multilib for those older applications (and some newer ones like Steam).
Debian is a notable exception. They fully support 32-bit x86 and Debian list i686 without MMX or SSE as a minimum. Debian would either have to raise that requirement or force their own compiler flags when they build Mesa.
Time is another factor that limits the real-world downside. It has been 16 years since since 2005. Dropping support for integrated Intel graphics in processors from 2013 is one thing. Those are less than 10 years old. Dropping support for processors that are 16+ years old does not seem as unreasonable.
Cui Bono or "To Whom Is It A Benefit?[edit]
GNU/Linux distributions can choose compile Mesa with whatever compiler flags (CFLAGS they want. If a distribution wants to make SSE 4.2 a requirement then they are fully able to compile Mesa, and everything else their distributions include, with -msse4.2. The only real change is that those who compile Mesa using the default compiler flags would get -msse2 without explicitly asking for it. There are some potential benefits to that approach from both a engineering/developer standpoint and a end-user standpoint:
"The value that I would imagine is:
- Encouraging distributions to build 32-bit Mesa with SSE2 (since presumably it provides better performance, and the vast majority of users' CPUs have SSE2)
- There are some annoying floating-point precision issues that go away when using
-mfpmath=sserather than-mfpmath=x87. I have seen at least one unit test in Mesa fail as a result of x87 precision differences.
(1) Is somewhat tenuous, since distributions are likely to control their own CPU baselines and ignore what Mesa sets (as Debian maintainers have said). And as of yet, we have no benchmarks.
(2) is kind of like... meh.
Compiling with -mfpmath=sse on 32-bit is still not as good as it could be, since the 32-bit ABI requires float/double to be passed in the x87 FPU registers anyway. All function calls have to move stuff between x87 registers and SSE registers and vice versa. :(
Interestingly, there's a GCC option -msseregparm that passes float/double arguments in SSE registers. It would be interesting if we could annotate internal functions with it."
on #dri-devel, March 28th, 2021
Just how much of a performance-gain Mesa would get if GNU/Linux distributions that do not set their own compiler flags get by compiling Mesa with -msse2 is anyone's guess without some actual benchmarks.
Making SSE2 a default would probably be worth it if the performance-gain is north of just 0.5% since the downside, a lack of support for 16+ year old hardware, does not seem like such a huge deal and distributions that really want to support that old hardware would still be able to override Mesa's default compiler flags and do so.
Please do feel free to comment below if you are actually using ancient 32-bit hardware without SSE2 support for some reason we can't begin to comprehend. You can likely get something newer for free if you ask around (don't expect that someone will just hand you a Ryzen era CPU, but you may find that there are a few people with something like an Athlon II in the basement just waiting to be driven to a recycling center or given away).
It is still unclear if Mesa will end up makign SSE2 a default or not. You can follow "Mesa issue 9868: Default enable SSE2 on mesa builds. Only post 21.1 release" to see how it goes. It would be a good thing if Mesa makes SSE2 a default for x86-64 builds since all x86-64 processors have SSE2 instructions, and it would probably not be such a bad thing if they make it a default for 32-bit x86 as well.
Enable comment auto-refresher