Fedora Developers Discuss Raising Base Requirement To AVX2 CPU Support

[Delgarde]

Out of my head, Core 2 and Phenom II's lack support and 4% (non-SSE4.2 capable) are just a third of 12 % (non-AVX capable) according to the Steam numbers mentioned earlier in this thread.

As someone on the Fedora thread pointed out, Steam numbers are counting only gamers - a group heavily skewed towards running on newer hardware. It's not going to be a representative sample of Fedora users...

[ms178]

As someone on the Fedora thread pointed out, Steam numbers are counting only gamers - a group heavily skewed towards running on newer hardware. It's not going to be a representative sample of Fedora users...

Right, these numbers are most probably not representative for the Fedora community but I guess they don't have better stats from their users available?

I was also reading that thread yesterday and there were some great ideas to move things forward without leaving out too many users. And at least I welcome the discussion about it. It is also up to the Fedora community to decide where a sensible cut could be made. I'd also like to see some concrete numbers with their distribution to see the benefits. But as Clear Linux demonstrates, there are some gains to be had from more target specific optimizations. Not everywhere, but there are places where it matters.

[IroLix]

Not gonna happen. May be not even in Fedora 35. Definitely not in 32 or 33 and even 34.

[IroLix]

Well currently almost any distro would be an option, all I want is 1 distro built with current hardware in mind.

Clear linux kinda does this, but is more an experiment than something designed for actual use.

Then it'd be better to have two official Fedora versions. One for Pre-AVX2 systems and the other for Post-AVX2 systems.

[arakan94]

I am all for going for modern technologies and increased effectiveness. Though it would be nice to see two versions - optimized and legacy. I would be using both.

[thelongdivider]

I fortunately use Arch. My current build is a Ryzen 1700. But I didn't decommission my 3700k system at that end of its life! Instead, I use it as a media PC and NAS.

I'm all for progress, but would like to see some supporting numbers to this AVX2 is necessary claim.

[discordian]

Jumping to ARM will just land you in the same position. Right now, the sane choice is to target ARMv8-A. That has mandatory support for 128-bit vector instructions (NEON), just like the SSE2 that's currently mandated by x86-64.

But, what's that I hear? You want bigger vector instructions? You could target SVE (Scalable Vector Extension), but that's even rarer than AVX-512 implementations (or subsets thereof), right now.

Here's a list of ARMv8-A extensions & release dates (source):

ISA Revision	Release Date
ARMv8-A	2011 Oct
ARMv8.1-A	2014 Dec
ARMv8.2-A	2016 Jan
ARMv8.3-A	2016 Oct
ARMv8.4-A	2017 ?
ARMv8.5-A	2018 ?

See? The fun doesn't end just because you jump ship and swim to ARM.

My comment about x86 was partly hyperbole, but it stands that there is no other CPU messed up near that amount.

• compatibility dating back to 8086 to be able to boot
• strong memory ordering
• a ton of horse-shittery you wont find elsewhere (System Managment Mode handlers primed from Bios)
• alot microcode (not just µops like ARM has)
• direct and slow path for ancient instructions
• x87
• incompatible extensions thanks to 2 vendors FMA4/FMA3

Yeah, ARM aint a totally clean arch either, but for the Desktop ISA they had a pretty linear path (since v6 atleast).

I can't say too much about RISC-V (link), as I haven't really been following it. Its instruction set is more modular, so I can foresee some gleeful times in trying to determine which of the 13 or so extension sets to target. And it seems each of those (plus the base) is independently versioned. Whoopee!

Mips and RISC-V would be the poster childs for a clean ISA. RISC-V extensions are to allow diversification for microprocessors and other special niches. The "desktop ISA" is a set of mandatory extensions, making these alot simpler.
For the vector extensions, RISC-V has no fixed vector width, you inquire the vector width at runtime and iterate over a loop (adding this width). The last iteration might not have full width, so there is a way to do a partial load and possibly even re-configuring the width of all instructions (OS will store that per-thread). Havent paid attention to the detail decisions, and the vector ISA is a work in progress.

[skeevy420]

Don't hold your breath.

Either that, or buy a grey-market import of one of these: https://www.anandtech.com/show/13381...rid-fireflight

They won't make a monster APU for two reasons:

1. Memory bandwidth.
2. Cooling

The memory bandwidth of a RX 580 is about 256 GB/sec, which you can't achieve without at least GDDR5. And that can't be installed in DIMMs - it has to be soldered onto the board.

Which is why I mentioned 8-16GB of whatever memory attached to the APU for just the GPU. Based on that link to the console, that's something that they could probably do; though based on the comments there, the 8GB GDDR5 is shared between Windows and the GPU which is likely going to make it perform well at 1080p medium or less...not really a SuperAPU with that configuration...but 8gb just for the GPU with whatever amount installed on the quad channel DDR4 for the system would change things up quite a bit and is what would make a SuperAPU worth having over a StandardAPU.

The issue of cooling is that you're taking a ~100 W CPU and a > 100 W GPU and putting them in the same package? 200 W CPUs are a big deal to cool! You're probably gonna need some water cooling, for that. Most people building such extreme machines are going to run a dGPU, anyway. This would narrow the market, substantially, making it less worthwhile for AMD.

I know, but "needs retarded levels of cooling" hasn't stopped AMD before; just look at the FX-9000 series. IMHO, this is the only real technical challenge with a SuperAPU and 7nm and less fabs will help with that.

Think about it: we've had consoles with monster APUs for almost 6 years. If AMD were going to build such a thing, what were they waiting for?

Tin foil hat answer: Either Sony or Microsoft has a "no SuperAPU clause" on AMD to not supply the consumer market with an APU that's better than their current gen console.

Or AMD doesn't want to compete with itself. If there was an SuperAPU, quite a few people would just buy it instead of a CPU and a GPU.

[eidolon]

You have to wonder if there is some kind of contest between Canonical and Red Hat on who can come up with more stupid poposals. Why is this even being discussed?

The author of the proposal obviously hasn't done *any* research. Some minimal research would have shown that this is a complete no-go given the current state of AVX2 deployment. There are also no numbers for the possible performance and efficiency benefits. Just some weasel words.

This reads like a proposal:
"After preliminary discussions with CPU vendors, we propose AVX2 as the new baseline."

This reads like an announcement (the timeline for which was later pushed back):
"The Ubuntu engineering team has reviewed the facts before us and concluded that we should not continue to carry i386 forward as an architecture. Consequently, i386 will not be included as an architecture for the 19.10 release, and we will shortly begin the process of disabling it for the eoan series across Ubuntu infrastructure."

By all means people having objections to raising the baseline to AVX2 is reasonable, but people having negative reactions to the mere proposal of it is not ('how dare someone have the audacity to propose this'). Developers should be free to pitch ideas (even overambitious ones) and discuss them. Discussion adds to the information gathering process and people can voice their opposition as well as suggest alternative courses of action (as has occurred).

What's up with developers lately? Where do developers get these ideas from? Why do these companies like to shoot themselves in their foot? (figuratively speaking) First Canonical with dropping 32-bit multilib support and now Fedora wanting to require AVX2 support (where the performance gain will likely be minimal in most use cases). If they want an optimized system, then why don't they recompile their own system or the specific packages themselves?

There's lots of older PC's (Core 2 Duo generation for example) running Fedora in the field, why cut support for all of that hardware? Even Microsoft Windows 10 works on that hardware.

This is a proposal, not an agreed upon course of action. This proposal does not mean all, or necessarily even most, Fedora developers want this change at this time,[1] just that some Fedora developers are eyeing this change at the moment.

[1] E.g. Look at some of the replies to the proposal from current FESCo (Fedora Engineering Steering Committee) members.

[carewolf]

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.

SSE3 is not that interesting. It would give too little over the current SSE2 minimum to be worth it. To get something that is worth updating minimum for you would need at least SSSE3 that has the all important byte-shuffle instruction that makes compiler auto-vectorization much better.
Or even better SSE4.1 that has the zero/sign-extend instructions, the blend instructions and the 32-bit integer multiply instruction (yeah, that was not in SSE2). But if you require SSE4.1 you might as well require SSE4.2, I think only two processors has been produced that has 4.1 and not 4.2.

Though I still have server at home with Phenom 2 that only has SSE3.. So it would not be nice for me. But then again I had an 2xAthlon 1800MP for over a decade until it was finally impossible to run anything on it as too much required SSE2.