Fedora Developers Discuss Raising Base Requirement To AVX2 CPU Support

[kpedersen]

Well, looks like the Wayland / systemd kids wanted Linux to change needlessly... well they have got to change too and update all their hardware needlessly!... probably every year from now on.

Hooray for progress! The only one to lose in this is... well Linux users (and the environment).

Edit: Just realized that I am typing this from a... P4 running FreeBSD-CURRENT (and things are running pretty darn smoothly without avx2)

[carewolf]

What are the expected benefits?

A loss of users, especially enterprise ones.

[ms178]

My current system is Westmere x5687 based. It's older, but it's also a dual processor, NUMA aware system with two 4c/8t @ 3.7ghz CPUs, supports godly amounts of registered ECC ram, kicks ass at 1080p gaming paired with an RX 580...for my Linux tinkering needs, it's perfect.

Before this one I was using a C2Q Q6600 with the FSB mod...the overclock to 3ghz with electrical tape trick...boy, those were the days . While not what I'd call a "gaming grade" system these days, it is still perfectly adequate for desktop work, multimedia viewing, audio work, and, like what you do, software testing. Anyone worth a shit tests on a shit-box. Do people not realize how many people use shit-boxes?

I am also writing this post from my secondary system with a Westmere X5675 @ 4.2 Ghz with 24 GB DDR3-1866 ECC RAM and a RX580. It is still a great gaming machine (albeit sacrificing security and power consumption for full performance), and I am running it with a custom Kernel config and compiled it with more aggressive compiler flags. As others pointed out already, there are other tricks like FMV to be more clever with such optimizations while keeping backwards compatibility. And yes, I don't see a point forcing people to upgrade when the benefit could be achieved with less invasive means.

[AsuMagic]

Too bad they can't work on some new compiler flags like "mtune=generic-sse3 march=generic-avx2" so we could have targeted binaries that would at minimum require an SSE3 CPU but would be optimized for AVX2 instructions if they're there.

You're thinking about function versioning. AFAIK though it is only possible for select functions manually.

[the_scx]

Yep. Won't be able to run on entre-level computers anymore..

Just make the requirement ~Nehalem, and they get most of the speed ups anyway with SSE4.

I think that Fedora Workstation with GNOME 4 should require GeForce RTX anyway, so CPU requirements wouldn't be a real problem.

[AsuMagic]

So whats the benefit outside of Games, HPC and possibly video encoding? Why not only compile those AVX2-only, I doubt most system libraries will care.
On the other hand, chipping away at x86 overboarding redundant crap is somewhat nice, but I would prefer just accelerating ARM/Risc-V replacements to get rid of the whole crap once and for all.

You can scratch games and video encoding. Games don't usually benefit from this on a library level, and video encoder/decoders usually make use of custom optimized assembly code paths, which are left unaffected by -mavx2.
I don't know what the developer who proposed this smoked, but gaining some percents on select workloads as a tradeoff to kill support for a ridiculous amount of people is insanity.

[AsuMagic]

The idea to require avx2 is completely insane (try again in another 10 years or so maybe...). Requiring fma is just as terrible (it's a separate feature, but afaik there's no cpu which implements one but not the other, and in any case fma definitely requires avx).
Now, requiring cmpxchg16b might be reasonable - this is what caused some trouble with windows 8.1 64bit, since 8.0 didn't require it and so on some cpus, namely older athlon 64 X2, it couldn't be upgraded to 8.1, but that's quite old hw...
But apart from cmpxchg16b I'm not sure you could really update the sse2 requirement.
SSE3 might be ok (even later P4 and A64 X2 support it, so in practical terms might be similar to chmpxchg16b support). The problem is, it's a pretty small extension and I have some doubts requiring it as baseline really makes much of a performance difference.
SSSE3 could possibly be ok too, although dropping everything pre-Bulldozer on the AMD side (and dropping everything pre-Core 2 from intel).
SSE4.1 would probably be quite controversial - I think on the AMD side it's the same as SSSE3, but on the intel side it's disabled on all (?) celeron/pentiums which natively can't do AVX (so, celerons / pentiums from the pre-Sandy Bridge timeframe, and atom cores pre-silvermont).
Requiring even "only" AVX is downright crazy imho and I bet it's not gonna happen.

I accidentally turned on SSE4.1 for the build of an indie game. Several testers immediately reported game crashes. Their CPUs were just too old to support a bitcount instruction from SSE4.1.
Now imagine that on the scale of a distribution with an order of magnitude more users AND with something even more bold such as AVX2.

According to steam stats about 4% of users do not have SSE4.1 support. That's pretty significant.
More than 12% of users do not have AVX support on Steam!

[skeevy420]

You're thinking about function versioning. AFAIK though it is only possible for select functions manually.

If not that, then pull an Apple and ship generic binaries and optimized binaries in the same package like they used to do with PPC and x86 binaries.

I'm just saying that we need some sort of middle-ground that lets people with newer hardware use their hardware to its fullest capabilities without screwing people who don't have the latest and greatest.

[AsuMagic]

Which will work still find with distributions of the era you bought them.

That's pretty hilarious because my shitty laptop Core2 from 2010 (which is still doing fine for my use) could certainly run Windows 10.
Like shit, but at least it wouldn't SIGILL because developers don't care about other CPUs than their fancy core i9 or ryzen 9.

[skeevy420]

I am also writing this post from my secondary system with a Westmere X5675 @ 4.2 Ghz with 24 GB DDR3-1866 ECC RAM and a RX580. It is still a great gaming machine (albeit sacrificing security and power consumption for full performance), and I am running it with a custom Kernel config and compiled it with more aggressive compiler flags. As others pointed out already, there are other tricks like FMV to be more clever with such optimizations while keeping backwards compatibility. And yes, I don't see a point forcing people to upgrade when the benefit could be achieved with less invasive means.

Same here. I have decent results using schedutil and using GameMode to switch processes like makepkg over to performance. Yes, I GameModed makepkg: you're damn right I want my compilers and insanely high XZ settings using performance.

All I know is that all of the articles like this are making me strongly consider leaving my Arch safe space and moving to Gentoo.