Mesa Considers Raising CPU Support Baseline

[Zan Lynx]

If people played around with the compiler optimizations like -march=native , they will know that it does not make a spectacular difference.
In reality newer machines were not held back that much.

Big gains can be made by rewriting certain functions in inline assembly using newer instructions.

Auto-vectorization can result in a 4x performance improvement. It all depends on where the time is spent in the code. And of course, what the code was doing before. SSE2 supports many calculations that MMX could not do.

And yes there is usually an even greater improvement with hand-tweaked assembly coding (or compiler intrinsics). In some cases the vectorized inner loop can reach the RAM bandwidth limit of the CPU. In that case the only performance improvements come from moving the code to a Xeon.

Seriously, there's a reason that running AVX2 code results in so much CPU heating. Because it is getting a LOT OF WORK DONE. It's worth it and the same is true of lower levels like MMX, SSE, SSE2, etc.

Besides vectorization, compiler optimizations add up. If you have a 5% boost from one thing and a 10% boost from another before you know it the software is running 30% faster.

Obviously, more modern CPU instructions work better than old ones. Otherwise we'd still be running 8 bit and 16 bit code and doing floating point using integer math just like the 1980s. Will anyone argue that recompiling 1980s 8086 code with -march=native is a waste of time and that it's not a "spectacular difference?" The changes do add up.

[Pentarctagon]

If you're compiling Mesa yourself, then you can set the flags to whatever you want so you don't care.
If you're not compiling Mesa yourself, then the distro you're using is setting their own flags on all the software they distribute themselves. The distro's supported CPU choice is what matters.

So... what difference does Mesa's defaults make?

[SilverBird775]

So... what difference does Mesa's defaults make?

The Mesa upstream may program efficient macroses for the vector math then.

[skeevy420]

Nobody but rabid Intel fanboys would recommend this for a custom build. The majority of those CPUs will go to OEMs.

For fuck's sake, an Excavator CPU from 2016 has AVX2. Let's hope Alder Lake Pentiums aren't that useless (lulz).

Well, then shame on OEMs.

That's why I support v# repos and not hardline cutoffs...granted, in this case the hard cutoff is v1 so no one 64-bit will be effected by this.

[rmfx]

Incredible that it's people with their 20yo config that lead the defaults in software.

Default should be based on average 5yo hardware and we should keep this offset.

Linux should drop 32bit build support because it's ridiculous, and support for cpu that are 20+yo should be removed.

[qarium]

I feel Linux should run on hardware older than 20 years because patents last 20 years. You think technology moves fast? Imagine how much faster it would move if patents didn't exist. If I could support a contemporary hardware vendor that only uses patent expired technology, I would, but my performance baseline for general computing is like a workstation from 2013 with support for h265.
So 16 years of patents left to go with the h265 codecs, but by then h268 will be out and would probably revolutionize everything again and increasing the baseline.
Technology only moves fast enough for expired patents to be almost worthless.

i would also support a hardware company who build patent free hardware.

but i think you are wrong about h265 believe it or not soon anyone will use VP9/AV1

this means a patent free hardware company could implement a VP9/AV1 decoder and you are fine.

[Azrael5]

I feel Linux should run on hardware older than 20 years because patents last 20 years. You think technology moves fast? Imagine how much faster it would move if patents didn't exist. If I could support a contemporary hardware vendor that only uses patent expired technology, I would, but my performance baseline for general computing is like a workstation from 2013 with support for h265.

So 16 years of patents left to go with the h265 codecs, but by then h268 will be out and would probably revolutionize everything again and increasing the baseline.


Technology only moves fast enough for expired patents to be almost worthless.

As stated, h265 is overtaken by AV1 and it is free. We are talking about a set instruction introduced 20 years go. If SSE2 is a problem Linux cannot improve because of hardware limitations. A cpu provided by sse2 instruction is sold for 5$. I have liked AGP video cards but I decided to switch to a pcie systems. Slowly, I upgrade my hardware over time based on important modern solutions. On legacy hardware, it is possible to apply Xp to play legacy games. So I suggest to match legacy hardware to legacy software avoiding risks of web exploitation, as well as to match modern hardware with modern operating systems. However if mesa could checks the hardware features in order to apply a kind of configuration compared to another one would be better. In this cas in fact, the hardware of every user would be optimized.

[hsci]

Why someone in 2021 should still use hardware of 20 years ago ?

Because it still works.

What next, people throwing away a SNES becaue it is old? Or a Airbus A330 because it is twenty years old? The problem is, that people feel the need or actual force to throw away smartphones, televisions and other stuff because it is older than 36 months.

Ideally CPU features get enabled at run-time (dlopen) or compile-time (GCC is your friendly helper). So modern system can go full speed an older systems can kept in use.

[angrypie]

Because it still works.

What next, people throwing away a SNES becaue it is old? Or a Airbus A330 because it is twenty years old? The problem is, that people feel the need or actual force to throw away smartphones, televisions and other stuff because it is older than 36 months.

Ideally CPU features get enabled at run-time (dlopen) or compile-time (GCC is your friendly helper). So modern system can go full speed an older systems can kept in use.

General consumer hardware is now designed to fail after a while. A brand new TV or smartphone isn't going to last more than a few years, and even if it does, manufacturers will release firmware updates to ensure it becomes shit. Tech-aware people might be able to revert it, but not your average consumer. These products are also designed to be impossible to repair.

PC components like motherboards, CPU and RAM are likely the only ones that increased reliability over time, which means that anything from 2009-ish onwards will greatly outlive its usefulness. I can't recall the last time I saw a dead CPU that wasn't DOA or was defective from the factory (like the speed-binned Zen1 CPUs and the wonderful segfaults they caused).

[txtsd]

How would I add these build flags on arch? Is it a meson flag?

https://github.com/archlinux/svntogit-packages/blob/packages/mesa/trunk/PKGBUILD