It's really funny that Linus have problem here, because it's just internal versioning for a set of features. If Linus has problems with simple versioning, why he use it for new kernel releases? He should release a long list of features, fixes etc. instead of some "stupid" numbers like 6.12.0 etc. Instead of "what the hell does 'v3' mean again?", we can say "what the hell does '6.12.0' mean again?".
Linus Torvalds Comes Out Against "Completely Broken" x86_64 Feature Levels
Collapse
X
-
Originally posted by Gonk View PostNo, any attempt to support AVX-512 was doomed before Alder Lake's e-cores came along.
I'd love it if Zen 6 turned out to be a solid green row.
Comment
-
-
Both Linus and the commenters here are pretty annoying about this.
While I don't think it's really necessary to have feature levels like this, it's not really much of a problem either. All I care about is what instructions are supported, which as Linus pointed out, isn't consistent. All I want to know is what version of SSE and/or AVX are available. Summing it up as a version doesn't doesn't say that much.
Comment
-
-
Originally posted by carewolf View PostI mean by all means get rid of v4, it was always speculation, and reality has gone a different direction. But v2, and v3 are somewhat useful outside of the kernel.
Thankfully, at least Kaby Lake and later are not affected because Intel released a microcode fix for those, but Intel simply couldn't be bothered to release the same microcode fix for Skylake. This broke quite a bunch of userland software, including various Electron stuff such as element-desktop, and it took *months* to get the fixes for these bugs merged, even though in most cases, the root cause was simply Electron using outdated versions of dependecies that had already fixed their flawed AVX/AVX2 detection routines.
Also, lets not forget how often Intel has disabled existing features in their CPUs through microcode updates in the past. The endless TSX odyssee is probably the most famous example, but another, more recent example is Intel disabling AVX-512 on Alder Lake through microcode updates.
If distros were to use the x86_64v* approach to specify minimum system requirements and built their packages accordingly, the next SPECTRE mitigation could easily render entire CPU generations worth of real-world systems unbootable, instead of "just" breaking some Electron software.Last edited by hardfalcon; 05 December 2024, 10:25 AM.
Comment
-
-
Originally posted by spyke View PostThis model is used in many places, not only in glibc. For example, in Vulkan new extensions are added every week and then at some point in time a subset of new extensions is marked as mandatory and labelled as a new Vulkan version. So, instead of saying the kernel requires [a list of 354 x86 instuctions] you can simplify and say "our baseline is x86_v3".
Linus is right, trying to represent something that is essentially non-linear as a linear v1, v2, etc. is a mental fallacy that is sure to cause more harm down the road.Last edited by bug77; 05 December 2024, 11:32 AM.
Comment
-
-
Originally posted by pokeballs View PostThey are useful, but to be honest I don't really care about the "linear" part. What we need is just some generic-avx generic-avx2 etc levels
Of course this can break in all kinds of ways. Though the most recent one was with ARM. For instance we had to override armv9 for Apple to force armv8, because they implemented an only partial and broken SVE in the M4 processor, but claims it is Armv9, but for the similar levels in the arm world is that v9 includes SVE, and the SME instructions Apple do fully support _require_ SVE, hence the partial and broken implementation of SVE (just enough to get SME working, and they advertise v9 because the manuals says to check for v9 before checking for SME). But that is the problem with ARM they keep these versionssets in the cpuid, making it possible for manufactorers to lie.
Comment
-
Comment