Intel completely disables AVX-512 on Alder Lake after all
igorslab.de
igorslab.de
Also see Linus’s rants in this thread: https://www.realworldtech.com/forum/?threadid=193189&curpost...
And the discussion: https://news.ycombinator.com/item?id=23809335
Today only benchmarks and HPC workloads use AVX-512. I’m sure Intel is happy to force HPC customers to pony up for data center CPUs.
From what I've heard, there's also a PS3 emulator that benefits greatly from it and its users are quite annoyed by this [0].
According to the sources, users would need to disable E-cores and preferably HT as well to get the best results, though. Pretty niche and not helpful in general (since disabling up to 50% of the cores/threads doesn't seem great for other use cases, but hey - 10% more performance in PS3 emulation).
[0] https://www.tomshardware.com/news/ps3-emulation-i9-12900k-vs...
I don't know the specificis of these CPUs, but it seems likely that _a sane design_ could allow heterogeneous CPU features within a single machine.
For example, let's assume two CPU feature sets, E and P. E is a proper subset of P. Further, an E core will issue an "illegal instruction" exception when it encounters an instruction that is undefined on E and _may be_ defined on P.
Now the OS becomes free to do what it needs to do: Run a program on whatever core, E or P; but if it gets an "illegal instruction" on an E core, check the instruction; if it would be valid on the P core, mark the program (or thread or whatever) as runnable on P-cores only.
It wouldn't all work optimally on day one, but it's hardly clear that it's impossible to make it workable. There are other 'niceties' you'd want, such as the ability for applications to query the 'biggest set' and 'smallest set' of CPU feature flags.
Would it be worth the work? I'd have to classify that an open question.
But of course you're totally right, and it's great to finally know the etymology of this particular misunderstanding.
Most [1] well-behaved software doesn't simply execute AVX-512 instructions (or any other recent ISA) to see what happens (this would just crash on any non-AVX-512 host), rather they query the ISA capabilities (via CPUID) and if AVX-512 support is reported, they'll use it.
So in your proposal, you need to decide what CPUID is going to report: does it report AVX-512 support, or not? Does it report differently depending on what CPU the CPUID instruction happens to run on? The latter option is a non-starter, because (a) it doesn't make sense and (b) the implied ABI is that CPUID ISA support won't change over the lifetime of a process.
So you are left with reporting AVX-512 on all cores, or none. If you report it on all cores, most processes will execute AVX-512, by the route of a few libc functions which are optimized to use the widest ISA available: so almost everything will end up pinned on the P cores, even if they get little benefit from it. OTOH if you report no AVX-512 support, well-behaved processes won't execute AVX-512 and trigger your dynamic migration in the first place.
Now you can imagine a greenfield where processes are aware of the hybrid nature of CPUs and then things might play out differently: but then you don't need the dynamic migration mechanism at all: since they are aware of what's going on, just have the processes hint to the OS where they should run.
---
[1] One exception is software compiled for a specific target ISA, e.g., -march=avx-512f or whatever. In this case the hybrid system kind of works: you compile your stuff that way if you want it to run on the big cores only, or with a lower-tier ISA if you want it to run everywhere. So it's like an opt-in to big cores w/o having to mess with affinity or other OS hinting.
1. You “accidentally forget” to disable the feature in hardware. Given how competitive the market is, motherboard manufacturers can be relied upon to enable it in their “1337 OVERCLOCKZ” mode. No conspiracy is needed.
2. You “tolerate” this practice just long enough to win the critical initial wave of reviews and benchmarks. Interested buyers will look at those charts for years to come.
3. And when you finally do turn the feature off to protect the market for your server chips, you can plausibly claim that you had explicitly forbidden using this configuration from the very beginning. None of this is your fault.
.
Edit/Addendum: Just to clarify my actual opinion, of course an honest mistake is more likely, at least for step 1. Very few “evil schemes” exist in reality because people aren’t all that clever (and all that evil). But the possibility is interesting to speculate on.
Of course, this could be evil Intel playing its tricks again but financially speaking removing AVX-512 do have tangible benefits to them in the form of increased microcode for the rest of the instructions (I want to see the detailed Alder Lake errata, maybe there's indeed a bug in another instruction that requires more microcode to implement - AVX-512 is an easy sacrifice for that).
Once you advertise a feature, you have to support it. It'd be pretty damn hard for Intel to explain why lower tier i5 and i3 CPUs have a feature that higher tier i7 and i9 SKUs are missing unless you jump through hoops via hardware (e.g. disable E-cores) or software (e.g. making sure to only run your process on P-cores).
If you want to experiment with AVX-512, just get an older CPU. Much less hassle for both Intel and their customers in this particular case.
An therein lies the difference. They advertise the feature, which is something they never did for AVX-512 on Alder Lake desktop. If they advertise a feature, they cannot disable it without getting into legal trouble.
If you get K-SKU, you get an unlocked multiplier. That's guaranteed by Intel and that's were their support begins and ends.
They cannot do the same for AVX-512, though, because that's not possible in their heterogeneous architecture. There's currently no desktop OS that supports different CPU cores (as in capabilities) on the same socket (or even board).
Such feature would require kernel drivers, thread schedulers, and possibly compiler toolchains to be modified for at least Linux and Windows and that's the kind of support Intel would need to provide. They did provide a thread scheduler, but to my knowledge that didn't include any AVX-512 related logic.
Nobody asks them to enable both AVX-512 and E-cores. People want them to not disable the mode that already works today -- P-cores only mode with AVX-512. There are no OS or driver reasons to not do that.
That hypothesis is not credible. They can simply declare a feature is unsupported, and even that using it voids some guarantee. I mean, look at how overclocking is handled.
There is no extra cost.
Therefore it would have a an e-fuse or a regular old 'current' fuse -- which is just passing a calculated amount of current through an intentionally thin interconnect so that it burns away.
1 - https://static.techspot.com/articles-info/1840/images/2019-0...
Is the average set of tests by, say, LTT or THG influenced by presence of these instructions? (not being snarky, I really don't know).
It might have mattered with the lower end Alder Lake parts that only have performance cores, but those haven't been released or reviewed yet.
Also "useful" and benchmarks do not mix well.
Long story short: Games generally aren't doing enough AVX to really benefit from it as implemented. They can be quite bursty in their use. Not to mention that Not every CPU even has AVX (because apparently Pentium Gold is a thing) even today.
If Intel convinced AMD to pick up the 256 bit versions and removed the clock speed penalties I could see them getting more use. But at the moment it's really just a feature for the HFT market primarily and even they are extremely careful in use because of the clock speed penalty. To the point they will literally benchmark both ways to make sure the penalty is overcome by the throughput.
Everyone else would not know that this might have a performance impact.
True, but those that try actual evil schemes must be watched for repeats. Remember Intel and Rambus?
Also... AVX-512 was never announced for 12th gen. No one claimed it was there, would work, would be stable or anything to that tune. No one should have had an expectation that a 12th gen CPU would do AVX-512 (and no one did). Intel even explicitly said pre-launch that it won't do AVX-512. Some people found post-launch that some BIOSes allow you to turn the E-cores off and that causes AVX-512 to be detected. IIRC not even the BIOS option claimed anything about AVX-512.
There are a lot one can criticize about Intel. Many low hanging fruits. This isn't one of them.
Don’t forget that reviewers made a huge deal out of the fact that CPUs downclock themselves when running AVX instructions.
Several reviewers tried to make this into some sort of scandal at the time, which I’d guess contributed to Intel wanting to remove the feature from consumer CPUs.
Of course, many of those same reviewers are now capitalizing on Intel removing AVX-512 support while ignoring the fact that you had to disable all of the efficiency cores if you wanted that feature (worsening thermals and performance in non-AVX) workloads.
It was and is kinda a huge deal. I followed the development of Corona Renderer for the past decade closely and one reoccuring theme with conflicting evidence was whether the inclusion of AVX was beneficial or detremental to performance due to resulting down clocking on certain platforms.
And surprisingly, now quickly looking through the search function, of the corona renderer forum an update apparently even dropped AVX because of better performance. ( https://forum.corona-renderer.com/index.php?topic=33889.msg1... ) Though I wonder if this is accurate or if the post is missing context...
This is severe restriction: even if could be limited to AVX instructions, running at 25% of the throughput would make AVX pretty useless.
This state persists only for a short time until a voltage and possibly frequency transition can be made at which point everything can run at full speed (albeit sometimes at a reduce frequency).
Of course because of lower clock speed and the associated penalties limit it a bit. But you can work around those limitations, for example perhaps by dynamically switching between AVX2 and AVX-512 paths depending on workload.
_mm_maskz_dpbusds_epi32 (avx-512 mnemonic "vpdpbusds"):
> Multiply groups of 4 adjacent pairs of unsigned 8-bit integers in a with corresponding signed 8-bit integers in b, producing 4 intermediate signed 16-bit results. Sum these 4 results with the corresponding 32-bit integer in src using signed saturation, and store the packed 32-bit results in dst using zeromask k (elements are zeroed out when the corresponding mask bit is not set).
They are so insanely specific sometimes that I really struggle to know what prompted their inclusion in the first place.
[0] https://www.intel.com/content/www/us/en/docs/intrinsics-guid...
It's effectively a low-precision 4-component dot product feeding into an accumulator, which means it is a building block for larger dot products. Large dot products are very useful both in signal processing for FIR filters, as well as machine learning algorithms. The masking is just a bonus available on most AVX-512 operations and lets you do branchless if conditions.
The majority of vectorized routines I've written have used a multiply-add building block like this, including image resizing, audio resampling and low/high pass filtering, and audio/video compression.
The applications that I mentioned wouldn't use all of AVX-512, but once you're familiar with vectorization it's not hard to tell what they are meant to be used for. CPU designers don't spend silicon on instructions that don't have a use, and AVX-512 does a lot to round out the vector instruction set to make it orthogonal and have less special cases.
The bad cases tend to be from instructions that are either too slow or are side effects of the general design. The horizontal add instructions in SSE4, for instance, would have been useful except that they were just as slow as manually doing the shuffles and adds yourself. AVX/AVX2 extended a bunch of SSE2-4 instructions to 256-bit by replicating them across lanes, which led to borderline useless forms like PALIGNR shifting within each 128-bit lane instead of across the entire vector. AVX-512 looks pretty good here though I have seen data about some mask operations being slow, not to mention the whole "slows down the whole chip" issue.
That having been said, it's hard to argue that AVX-512 _isn't_ mostly useless, if for no other reason than it being mostly unavailable. Baseline AVX-512 has a market penetration of only 5.6% in the Steam hardware survey and Intel shipping their latest chip without officially supporting it isn't going to help that. Only niche software can afford to use it right now.
If I want to play with it (as programmer who is interested in DSP on generic-purpose hardware) I need to rent special cloud instance for very non-hobby-friendly price. Additionally, benchamrks (of algorithms, not hardware) at shared instance is never good idea.
I have old (but fast enough for most my tasks) i7-6700K at my desk now, and I've hoped to upgrade it to something with full AVX-512, but alas. What is cheapest way to have local AVX-512 capable system (I know about exotic, low-power i3-8121U, lets ignore it)?
Unless developers will be able to buy reasonable-priced (think: current i5/i7 non-extreme prices, middle-level MoBo, not low-end, but not gaming or server one) system, AVX-512 will be completely irrelevant.
Yes, GPUGP is affordable now (or not? Prices for video cards are insane!), but not all tasks goes well with GPUGP, where transaction cost is insane (memory is slow, but PCIe is much slower and has much larger latency).
Update: And no, I don't need any "effective" cores at my desktop, thank you. I'm not sure, I need it on my laptop, either, but I'm pretty sure about my desktop.
Isn't that true of like 99.9999% of CPU features? I have never seen an Intel presentation or piece of marketing material that said my software would be able to use the EAX register, and yet it keeps showing up year after year.
e.g. https://www.intel.com/content/www/us/en/products/sku/226066/...
Even in the nuke simulations it is rarely used. More recent cores might be better, but the frequency drop and the associated latency kill performances on the clusters I know. And the new generation ones are AMD anyway.
But yes, I'd rather have twice the cores and memory bandwidth with AVX2. For those that don't know: non-benchmark code usually doesn't get close to peak floating point performance, constrained by memory bandwidth and/or inter-node communication. Everyone is trying to get the compute performance from GPUs anyway.
And as you say, if you have to redesign the code you might as well do it for a GPU that does not have the same issues.
For varying mileage, I'm more familiar with, say, molecular dynamics codes, where Gromacs, for instance, has its own hand-tuned avx512 in places, and cp2k might use it at least for FFT, small matrices (libxsmm) and eigenfunctions (ELPA), as well as BLAS. Elsewhere, some R applications (on the desktop in this context) might hit BLAS heavily.
I should have made the point that there's avx512 and avx512, for people who don't know. At least GCC and LLVM -march=native does half-width SIMD on SKX et al because of throttling. If you wonder where a factor of two went, -mprefer-vector-width=512 might help.
Your applications don't do linear algebra or FFT? AVX-512 is overrated for HPC generally, but it's surely going to be used by an optimized BLAS (unless there's only one FMA unit per core if the implementation is careful).
Compute nodes actually should have a big.little structure with a service core for the batch daemon etc.
Elsewhere, I see ~130 AVX512 instructions in this Debian system's libc.
That’s not what happened here.
The AVX-512 instructions not only weren’t enabled by default, they couldn’t be enabled at all unless you went out of your way to disable the efficiency cores completely. They also wouldn’t benefit your workload unless disabling those extra cores was offset by the AVX-512 instructions on the remaining cores.
None of the benchmarks you saw in reviews or marketing material would have used these instructions unless specifically called out by the reviewers as having made all of these changes.
Benchmarks like the multi-core Geekbench would actually go down, not up, with this enabled because you’re giving up cores. Thermal performance would be worse because the efficiency cores were disabled.
Intel never marketed the part with AVX-512. It was discovered by a reviewer poking around in the BIOS of a review board.
> motherboard manufacturers can be relied upon to enable it in their “1337 OVERCLOCKZ” mode. No conspiracy is needed.
Nope. You had to disable cores to enable AVX-512 and I doubt it would show up in any gaming or consumer benchmarks as a positive.
The conspiracy theory about Intel doing this to mislead consumers not only doesn’t make sense, it’s completely wrong given how this worked and how it was discovered.
If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too. Sixteen 256-bit AVX channels are the same as eight 512-bit channels in theoretical throughput. Because there are fewer load/store commands and fewer bunches of setup code to run, overall theoretical efficiency should be higher.
Power efficiency was a killer at 14nm. The cores would downclock into oblivion when AVX-512 executed. Given the node shrink and shutting off half the cores, I don't see why this would happen here. Doing the same calculations with less power means a lot for the kinds of workloads that actually use AVX-512. Sure, idle performance may go down a bit, but once again, if you're running the kind of application that benefits from this, that's also probably not a top consideration either.
The real solution would be for Intel to detect the presence of AVX-512 instructions then automatically and unconditionally pin the thread to the big cores. It wouldn't be hard either, just catch the unknown instruction exception and see if it is AVX-512 then move the thread.
Maybe if you have a poorly parallelized problem where the bulk of the code is spent in AVX-512 instructions and you don’t ever do anything else on the computer, but that’s going to be rare for any consumer.
> The real solution would be for Intel to detect the presence of AVX-512 instructions then automatically and unconditionally pin the thread to the big cores. It wouldn't be hard either, just catch the unknown instruction exception and see if it is AVX-512 then move the thread.
“It wouldn’t be hard” is a huge understatement. This is OS-level support, not something Intel can just do inside the CPU. And operating system vendors and developers are still catching up to basic Alder Like scheduler support without AVX-512 handing, so it’s not reasonable to suggest this would be easy.
For a first step it would have been enough to manually pin threads to the big cores for adventurous users, but Linux already tacks which threads use AVX (since it comes with a clock penalty, so you want to isolate them if possible), it's not unreasonable to think that auto-setting CPU mask based on that should be possible too.
Having actually worked on this, it’s quite a bit more complicated, although it is possible. For better or for worse, though, Intel made a decision that all cores would expose the same feature set, and now this is baked into Linux and probably other OSes at the ABI level, and changing it would be a mess.
A correct heterogeneous ABI (and frankly a good AVX512 ABI at all) would require explicit opt-in, per process, for AVX512. Opting in would change the signal frame format, the available features, and the set of allowed cores.
(The issue is that AVX512 (the actual 512-bit parts, not the associated EVEX and masking extensions) may well be excellent for long-running vector-math-heavy usage, but the cost of switching AVX512 on and off is extreme, and using it for things like memcpy() and strcmp() is pretty much always a loss except in silly microbenchmarks.)
To be clear, I don't like the type of product line differentiation that Intel does, and I think Intel should have supported proper heterogenous ISA systems so that AVX512 and related technologies on client systems would make sense, but I don't think any of this is nefarious.
This paints a picture of what happened to Intel's fab process rather than AVX-512 itself.
AVX-512 was proposed back in 2013. It was NOT designed for desktops. The original designs were for their Phi chips (basically turning a bunch of x86 cores into a GPU). These Phi chips ran between 1 and 1.5GHz, so power consumption and clocks were always matched up.
Intel wanted to move these instructions into their HPC CPUs. The problem at hand was ultra-high turbo speeds. These speeds work because the heat is a bit spread out on the chip and a lot of pieces are disabled at any given time. With AVX-512, they had 30% of the core going wide open for the vector units (not to mention the added usage from saturating the load/store bandwidth).
They wanted 10nm and then 7nm to fix these issues. At their predicted schedule, 10nm would have launched in 2015 and 7nm in 2017.
Given the introduction of AVX-512 in 2013, they had plenty of time. In fact, the first official product was Knight's landing in 2016. Skylake with AVX-512 didn't launch until 2017 when they were supposed to be on 7nm.
Intel was forced to backport their designs to 14nm++++++++++++ which forced a deal with the devil. They had to downclock the CPU to keep within thermal limits, but this slowed down EVERYTHING. Maybe they could have created a separate power plane for AVX, but this would be a BIG change (and probably politically infeasible).
What happens with the downclocking? If you run dedicated AVX-512 loads, then maybe you should have been looking at Phi instead. If not, mixed loads suffered overall because of the lower clockspeeds.
Their second revision of 10nm superfin is still a generation larger (well, probably a half-generation) than what they anticipated. There might still be downclocking, but I'd guess that it's nowhere near what previous iterations required.
TL;DR -- AVX-512 was launched two nodes too early which screwed over performance. It should become acceptable either with 10nm Superfin or 7nm when it launches so the CPU doesn't have to downclock constantly.
The overwhelming bulk of my research does not use Gromacs, however. Mkl, matrix algebra and similar hybrid MPI tasks, yes, but oddly there the extensions really don't seem to do much, and frankly the inferior memory architecture of the Xeon platinum nodes we use makes itself apparent. I frequently get annoyed that Intel charge you a fortune for CPUs into which you can put a ton of ram, and then marketing makes the CPU's exclusive feature an instruction that doesn't seem to help that much in my actual workloads.
They really should just shunt it to some specialised product and use the die space for something else. I'm with Linus here.
Wouldn't it be entirely up to the OS to decide on what core(s) a thread will run?
Intel even touted the work they did with Microsoft about the scheduler to deal with selecting which E or P core to use.
I’m not sure why they chose to disable AVX-512 instead of doing that. Maybe that is their end goal, but it’s too much effort to have it done by release.
- ME https://news.ycombinator.com/item?id=21534199
- Anti Trust: https://www.networkworld.com/article/2239461/intel-and-antit...
- The cripple AMD function in their compiler: https://www.agner.org/optimize/blog/read.php?i=49
I could keep this up quite a bit longer if you want. Intel well deserves any skepticism and cynicism it is targeted with.
Intel deserves skepticism and cynicism based on what is true.
Also, groups of people are really bad at keeping secrets. In my experience most orgs that do bad things find a way to make everyone think that it’s either actually a good thing, or that someone else is responsible for it. If you make people think there’s a dark secret, they’ll tell eventually.
Uh, no. That is a very common technique commonly used the last 15 years.
Many products have different parts, such as different types for display panels in different revisions. So a very common tactic is to only release the one with the superior part at first.
And a few weeks/months later all the reviews have been written or at least have sourced their review sample you start pushing the cheaper version.
Mobile phones, computer displays, TVs etc. suffer from this. Perhaps less so nowadays because most of those critical components are specified in the spec. sheet.
Problem with this scheme is that it assumes reviewers will go to length of running a special hidden mode which may have value in some fringe cases and rave about it.
- Let's thread this thing.
- OMG things are working N times faster (where N=cpus)
- 1 year later, shit... In 0.1% of the cases there is race condition and we can't figure it out, random garbage to our data...
- 1 week later rolled back to single thread and now everyone is complaing why things are slow...
- This actually happened... (just not the same time frames)AVX-512 isn't advertised by Intel as a 12th gen desktop CPU feature and doesn't provide any advantages for most desktop users anyway.
Sure, there's niche applications like some particular PS3 emulator, but I don't share the author's opinion w.r.t. to performance and efficiency in desktop use.
On more recent cores, there's only ~100 MHz of downclocking, which is so small you can pretty much ignore it.
If Intel was able to get Icelake out on time, it may have reduced the "stickiness" of the myth.
I don't know if it was super good (Linus Torvalds certainly was loud against it, and from his POV, his critic makes lots of sense), but I run some numeric code from time to time that _in theory_ could benefit from it. So it's a bit of shame that it won't be supported in future products? Let's see what AMD does about it on Zen 4 and if they manage to force Intel back to it, if only for competitions sake.
[0] https://travisdowns.github.io/blog/2020/08/19/icl-avx512-fre...
My comment was about Alder Lake, where only P-cores even have AVX-512 units.
The i9 has 8 P-cores and 8 E-cores and users need to disable the 8 E-cores to use AVX-512. That's 50% of the cores gone for very niche use cases.
Considering that the PS3 emulator only got ~10% better performance on the highest end, it'd be better to simply get an 11th gen high-end part instead of a lower end 12th gen CPU for that use case anyway, so I really don't understand what the fuss is about.
Even then, you're not turning off half the cores:
* Area wise, 4 E-cores use as much die space as 1 P-core.
* Thread wise, turning off the E-cores brings you from 24 threads down to 16 threads.
* I didn't see the PS3 emulator benchmark, but you are telling me that they got a speedup.
* There are some anecdotal accounts ("hardware influencers", YouTube channels, etc) about P-cores being the main driver for gaming performance, hence why these sources mainly recommend the 12400 processor with no E-cores as a price/performance sweet spot.
* Of course, not everything is gaming, and depending on what you do with your computer(s), what will work better.
All in all, I'm more interested in the Celeron/Pentiums which will be Gracemont only (E-cores) and what kind of performance, battery life they get from them. I have an old (2018) sub-notebook that houses an N4000 Celeron (that'd be Goldmont+), and it was surprisingly good for answering emails, web browsing and watching online video. Abysmall performance if you tried to do anything that required math with it (10x to 100x slower than an i5 from the same time) but apparently they've ironed out all those things and those little cores can get in the same ballpark performance, at a much lower power envelope.
However I would say avoiding Intel completely is unnecessary. They're a good FOSS citizen when it boils to things like WLAN and GPU.
Its just that with AMD, you can hardly go wrong on CPU and GPU side. Especially on Linux.
And they - rightly - get plenty of flak for it.
As soon as you want to use Linux or macOS or Proxmox or anything, prepare for trouble. Its just not a FOSS-friendly company.
Even on the Nvidia Shield TV (a great bang for the buck) they added commercials in the new UI. Though one might attribute that to Google, it is the only Nvidia device I bought past 5 years. And the only one which got a feature downgrade (or upgrade with a feature I don't want/like).
With regards to Intel I remember my 4770k not having a specific feature (IIRC for hardware virtualization) which all non-k series had. And I found that out too late.
It even works with multi-screen setups and using the rest of the memory for CUDA.
You don’t get flipped off by Linus T for having good drivers. You also don’t have to wait years for wayland to work if your driver is good.
Maybe I've just been lucky but over all that time not a single glitch. The main gripe I have with them is having you jump through hoops to be allowed to download certain libraries. That's just a complete nuisance. And I think their TOS are unethical.
The NVIDIA driver on Linux is extremely good and in my experience of better quality than AMD, but sorely lacking in modern features such as Wayland support. We still don't have decent hardware encoding nor raytracing support on AMD, the champions of free software, while DLSS and NVENC have been running on Linux for a while now.
I run AMD GPUs now but I'm quite done with the NVIDIA hate boner the Linux world has.
They'd have to license TB from Intel. I don't know about TB4, but TB3 is royalty-free, just gotta pass a certification.
TB3 or better would be great for eGPUs in general. Not sure I personally would need TB4.
Also, I wonder if Framework would be usable with say Proxmox and macOS (or 'native' Hackintosh?)
What does tb4 offer over 3?
The short answer for Thunderbolt 4 over Thunderbolt 3 is "a second 4K display" thanks to double the PCIe bandwidth, 16Gbps vs 32Gbps. (The main data channel is 40Gbps in both.)
USB 4 is actually a bit more constrained than Thunderbolt 3, at 20Gbps data channel, and no guarantee of PCIe bandwidth.
> Thunderbolt 4 guarantees support for one 8K display or two 4K displays. A USB4 port can only support one display with no mention of resolution minimums. And even that isn't required as some USB4 ports will not support video at all.
Finding it hard to keep up with tech lately :D
I got 2x 1440p monitor and won't upgrade either any time soon. So I suppose if I were to use both of these, I'd be fine with TB3 and eGPU?
It's mostly the same though and devices should be cross-compatible.
Primarily you want TB4 for the stricter requirements for certification.
Except you cannot disable AMD PSP.
Then again everything I think that way about is apparently a mortal sin in the business world.
Personally, I don't care much about firmware being proprietary, if it cannot be used to meaningfully change the functionality of the chip. But I do care about the chip ultimately following a public specification. I want an ISA just like x86, ARM, or RISC-V. Tell me the size and format of the ring buffer I must write to or read from, and I'll program the rest.
But even that is still too much to ask for apparently. Graphics cards are getting closer with lower level drivers like DX12 and Vulkan, but we're not quite there yet.
My biggest problem is that figuring this state of affairs out is like pulling teeth.
Besides, there are other ways to get that flexibility. CPUs for instance have a very flexible ISA: even if they’re set in stone, we can use them for pretty much anything, the only real limitation being performance.
Now when I think about it, even if firmware can significantly change the functionality of a chip, I don’t care too much of it being proprietary. Not more than I care about fixed hardware being proprietary. It’s okay for a piece of hardware to have 3 or 10 different configurations, as long as (i) I can trust that each configuration works as advertised, and (ii) the ISA I got from each configuration is publicly documented.
There’s a practical reason for this wish: hardware is typically orders of magnitude more reliable than software. That’s mostly because buggy software is easily updated, while flawed hardware is often impossible to sell. CPU bugs do happen, but they’re sufficiently few and far between that when my programs behave unexpectedly, I can safely assume it’s the software’s fault.
I don’t want drivers any more, I want the hardware’s manual. https://caseymuratori.com/blog_0031
Most of us here think of copyright in the way Disney or Nintendo thinks of copyright: we own the thing, and you don't get to touch the thing. However, to actually get 100% ownership over a copyrighted work, you actually have to make 100% of the work. If you're just buying what you need to make the thing work, then your ownership over the resulting software is going to be thin. After all, the people who sold you the software are going to want to be able to sell it to other people, and in order for that to work, those other people need to not have the software. Which means that all those licenses are going to have provisions on further redistribution so that they still have their copyright monopoly.
If you want to release source, then you have to go back to everyone you bought software from and renegotiate licenses on a far more expensive basis. Because you're asking them to take all the money they will ever make on that software all in one go. For similar reasons, things like licensed music tracks in games are far cheaper if the license is for a limited time, because then the record label can ask for more money later on. The irony of proprietary software development is that it can actually be just as collaborative as Free; but only if every participant regularly pays back into the system.
In contrast, the Free Software world tends to have some of the strictest copyright hygiene in any software industry. You have to, because the whole point is to more or less waive copyright interest in the code - and to do that, you need to have Disney-level ownership over everything. We can thus look at copyright as a sort of deliberate cultural poisoning that puts software developers and artists into the position of having to demand troll tolls everywhere.
Libreboot disagrees with that: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-....
Also, FSF would never endorse an Intel CPU with disabled Intel ME. It must be fully removed to get the RYF certification.
Except it relies on proprietary drivers, which will not be updated by the vendor, resulting in a brick after some years. Librem 5 and Pinephone will receive software updates forever.
> But you're bound to old, refurbished ones (X230/T430 apparently) [1].
Not necessarily: https://forum.qubes-os.org/t/community-recommended-computers....
> Librem 5 delivers awful performance
What do you mean? It can run 3D games and provides full desktop mode. What else do you need?
Ah yes, that phone where the FSF told them they had to move a blob from the bootloader into an external Flash memory and load it through two layers of CPUs, because going through that pointless dance magically makes it Free™ (read: hidden enough that users won't notice so they won't realize they're still running a blob as part of something as critical as making the RAM work).
Also that phone which runs a pile of other giant blobs, including the USB-PD controller and the baseband, of course.
The baseband is on the upgradable M.2 card, also has no access to anything. It can even be killed with a hardware switch. The best smartphone you can find if you care about it. Nobody says that other blobs are fine, but it's already a huge step to the freedom.
The proprietary software literally configures the RAM on the phone. It is critical for making the RAM work, of course it has access to the RAM! Supposedly it should be quiesced after training, but I haven't seen any security analysis that claims that firmware couldn't just take over the system while it runs.
But they added an extra two layers of indirection, even though the blob ends up running on the same CPU with the same privileges in the end anyway, because all that obfuscation let them get in via the FSF's "secondary processor" exception somehow. Even though the end result is the same, and you're still running a blob to perform a critical, security-relevant task.
If the goal is security ("blobs can't take over my system") and stuff running during the boot process doesn't count, then Apple's M1 machines are on precisely the same level as the Librem 5: they also run blobs on boot, and at runtime all remaining blobs on separate CPUs are sandboxed such that they can't take over the main RAM/CPU.
> Supposedly it should be quiesced after training, but I haven't seen any security analysis that claims that firmware couldn't just take over the system while it runs.
I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise.
> even though the blob ends up running on the same CPU with the same privileges in the end anyway
This is not how I understood it. The Librem 5 stores these binary blobs on a separate Winbond W25Q16JVUXIM TR SPI NOR Flash chip and it is executed by U-Boot on the separate Cortex-M4F core. From here: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....
It absolutely wasn't. Look into it. In every case, the blob ends up running on the RAM controller CPU and supposedly finishes running and is done. The whole point of the exercise was obfuscating the process which is used to get to that point such that it avoided the main CPU physically moving the bits of the blob from point A to point B. Really.
> This is not how I understood it. The Librem 5 stores these binary blobs on a separate Winbond W25Q16JVUXIM TR SPI NOR Flash chip and it is executed by U-Boot on the separate Cortex-M4F core.
That is incorrect (great, now they either don't know how their own phone works or they're lying - see what I said about obfuscation? It's great for confusing everyone).
The M4 core code is not proprietary; it's the pointless indirection layer they wrote and it is not loaded from that SPI NOR flash. It's right here:
https://source.puri.sm/Librem5/Cortex_M4/-/tree/master
That open source code, which is loaded by the main CPU into the M4 core, is responsible for loading the RAM training blob from SPI flash (see spi.c) and into the DDR controller (see ddr_loader.c).
The actual blob then runs on the PMU ("PHY Micro-Controller Unit") inside the DDR controller. This is an ARC core that is part of the Synopsys DesignWare DDR PHY IP core that NXP licensed for their SoC. Here, cpu_rec.py will tell you:
firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem.bin
full(0x5ac0) ARcompact chunk(0x4e00;39) ARcompact
https://github.com/u-boot/u-boot/blob/master/drivers/ddr/imx...
Same code, just running on the main CPU because it is absolutely pointless running it on another core, unless you're trying to obfuscate things to appease the FSF. And then the blob gets appended to the U-Boot image post-build (remember this just gets loaded into the PMU, it never touches the main CPU's execution pipeline):
https://github.com/u-boot/u-boot/blob/master/tools/imx8m_ima...
Purism went out of their way and wasted a ton of engineering hours just to create a more convoluted process with precisely the same end result, because somehow all these extra layers of obfuscation made the blob not a blob any more in the FSF's eyes.
The security question here is whether that blob, during execution, is in a position to take over the system, either immediately or somehow causing itself to remain executing. Can it only talk to the RAM or can it issue arbitrary bus transactions to other peripherals? Can it control its own run bit or can the main CPU always quiesce it? Can it claim to be "done" while continuing to run? Can it misconfigure the RAM to somehow cause corruption that allows it to take over the system? I have seen no security analysis to this effect from anyone involved, because as far as I can tell nobody involved cares about security; the whole purpose of this exercise obviously wasn't security, it was backdooring the system into RYF compliance.
Who's "they"? This is an unofficial community wiki.
I will edit the FAQ answer to clarify that the DDR training blobs are being executed on an ARC core in the DDR controller, and not on the M4 core. I was going off what Angus Ainslie wrote (https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...) that 'the M4 is the “secondary processor” that handles the blobs', and I conflated "handles" with "executes".
However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules, and Ainslie's article on the Purism web site and Nicole Faerber's talk (https://media.ccc.de/v/Camp2019-10238-a_mobile_phone_that_re...) both explained how Purism is using the secondary processor exception in the RYF rules.
It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5. Raptor Computing is now facing the exact same problem with the proprietary Synopsys DDR4 timing blobs in the POWER 10 processor, so this is actually a common problem with most modern processors. It seems to me that Purism did the best that it could with an impossible situation, and if anybody should be criticized it is the FSF for not acknowledging how modern hardware actually works.
Another thing that I find problematic is your argument that 58 KB of DDR4 timer training blobs represent a security threat in the real world and make the Librem 5 no different than an Apple device with an M1 processor, which is literally a black box. Forget the fact that the L5 is the first phone to have free/open source schematics since the GTA04 in 2012 and we know the 1267 components on its PCBs, plus we have 7000 pages of documentation for the i.MX 8M Quad processor, and everything is running free/open source drivers.
There is only so much code that you can hide inside 58 KB of blobs and that early in the boot sequence, you can't rely on anything else being operational in the device, so you would need to have all the code to initialize and control components on the phone. Think about how much code would be needed to initialize the cellular modem or WiFI and then run a TCP/IP stack to communicate with the outside world. It isn't hard to verify that the blobs that are stored inside the L5's SPI NOR Flash chip are the same ones being distributed by NXP, so then you are left with the theory that NXP or Synopsys are distributing blobs that do something malicious, which would be suicidal for either of those companies if anyone ever discovered it. Supermicro's stock lost 40% of its value after Bloomberg published one story about the Chinese government inserting spy chips in Supermicro motherboards, and nothing in Bloomberg's article was verifiable. Companies like NXP and Synopsys are very unlikely to risk their businesses, even if the NSA asks them, so I find the whole scenario far-fetched.
> However, you seem to be unfairly criticizing Purism for obfuscation and legalisms, when it seems to me that Purism is just trying to comply with the FSF's rather arbitrary RYF rules
The question is why are they doing that? Why are they pandering to a program which ends up encouraging less free devices? RYF is completely broken and does not deliver what people think it does, and the FSF have shown zero interest in educating users about what it means and doesn't. It is a feel-good program that actually hurts the ecosystem behind the scenes. Why is Purism lending it legitimacy by attempting to get certification?
They should've done what bunnie did after Stallman showed up with that crazy "fuse the GPU off" idea: give up on this nonsense and focus on delivering a device as free as possible, instead of wasting engineering time pandering to a program that isn't helping anyone.
> It is not like Purism had any better options in terms of SoC's that it could have chosen for the Librem 5.
Indeed, and this is the crux of the problem: 100% libre modern hardware is impossible in the current world, but the FSF and people who buy in to their tactics keep pretending it is. That there is some magical line that denotes a device as "freedom-respecting" and they can just put things in that bucket and slap a sticker on it and sell it to all those freedom fanboys. This encourages further ignorance: users don't have to think about practicalities such as what security risks are actually present or what the lack of source code for some components might do to affect things they might practically want to do. They don't have to think about whether things are signed or validated, or how to verify that they are running software that is at the very least trusted to be a widely available build, or anything like that. They just see "no blobs in my filesystem!" "freedom!" and declare that device as a Friend of Free Software. And then they extrapolate from that a bunch of properties that are absolutely not implied, around privacy and security and more.
> It seems to me that Purism did the best that it could with an impossible situation, and if anybody should be criticized it is the FSF for not acknowledging how modern hardware actually works.
Purism did a decent job with the hardware; the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem.
> Another thing that I find problematic is your argument that 58 KB of DDR4 timer training blobs represent a security threat in the real world
Oh, they absolutely don't. In practice they don't; they also do not present any practical restriction on freedom. Even if the training code were open, I bet there isn't a single person who would ever modify it on a shipping device (especially one with soldered RAM). That's the kind of thing you need 6-figure test equipment to validate properly, and there is no reason to go mucking with it for any end user of the hardware. It existing as a blob causes zero reduction in practical freedom for users, because source code for it would only give you theoretical freedom that nobody wants or needs to exercise.
But you see, the entire FSF culture isn't about practicalities. That's the whole problem with it. It is about platonic ideals and philosophical arguments, and completely eschews looking at how real people are affected by software being open or closed. And from that point of view,
> and make the Librem 5 no different than an Apple device with an M1 processor
They indeed make it no different, because in both cases you're running blobs on boot, and you're in the same practical situation from an absolutist point of view, modulo the FSF's backdoor arguments.
> which is literally a black box.
How so? The i.MX8M is also a black box by that token; it's a pile of silicon. Sure, it may be (partially - those SoC programming manuals always have censored parts) documented, but it's not open hardware. You can't know what it does precisely. You can't prove the absence of a backdoor any more than you can with the M1.
> Forget the fact that the L5 is the first phone to have free/open source schematics
I have schematics for some of my M1 Macs. Sure, they leaked and were not willingly published... but in the end, I have them and can look things up in them. So for analysis/educational intents and purposes, I'm in a similar situation as you are with the L5.
(Of course it makes a difference in corporate goodwill that Purism published them deliberately; I'm just pointing out that you're limited to that aspect, since at the end of the day, we both have schematics for our devices, so we're both in the same situation as far as being able to understand them).
> and everything is running free/open source drivers.
We're working on that for the M1. You can run Linux on the M1 today with fully free/open source drivers for most critical parts of the hardware. This blog post has a table of hardware support and upstreaming status:
https://asahilinux.org/2021/12/progress-report-oct-nov-2021/
Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally.
I submitted upstream bring-up for the M1 Mac Mini with the device tree on Feb 4 2021, just 4 months after it was announced in Nov 2020. And that was working from scratch, on an unknown SoC, reverse engineering everything, having to make more intrusive patches to Linux because this SoC is quite "special", having to write our own pre-bootloader from scratch, etc. A year after release, we have a bunch more hardware working and on the way to upstreaming, including sound on the Mac Mini, I2C, SPI, NVMe, keyboard/trackpad on the laptops, USB and USB-C, power management, basic screen/display controller support, Wi-Fi (including on prior Macs going back to 2017), and support for 9 distinct hardware platforms including the just-launched M1 Pro and M1 Max models, which were already at feature parity a few weeks later. Given all that, I'd say we're doing a lot better with M1 upstream support with fully free drivers than Purism did, timeline-wise. And we didn't need a SoC programming manual. Maybe it's because we aren't wasting time trying to get RYF certification? :-)
Fun fact: the L5 and the M1 Macs use the same line of USB-PD controllers and share a driver, so it is very likely that some of our work on that front will benefit L5 users. The existing driver is very bare-bones and definitely needs more work.
> Think about how much code would be needed to initialize the cellular modem or WiFI and then run a TCP/IP stack to communicate with the outside world.
The M1 is in that situation too: Apple's bootloader is bare-bones and doesn't even support USB, let alone networking (by design). The Wi-Fi firmware is larger than the first-stage and second-stage bootloaders put together. The whole thing boots too fast to go around initializing Wi-Fi (just firmware upload and boot takes a few seconds on these modules...) and associating to a network and phoning home. And due to the SoC design, after boot, no proprietary code remains running on any secondary core with the ability to take over the system; all auxiliary cores running firmware are sandboxed behind IOMMUs, and the main CPU does not have the ability to run a secret supervisor/hypervisor under the OS (it can run a hypervisor but that cannot be done surreptitiously and silently; the guest knows).
And of course, given how Apple is constantly under attack by nation-state-sponsored entities like NSO, they have every incentive to fix security problems and build systems that are very difficult to compromise. To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might), nor does it make any attempt at being secure against physical access attacks (e.g. evil maid). The M1 does. I can install my own Linux bootloader, which requires entering my machine owner credentials, and know that nobody else can take over the device without wiping storage entirely via DFU mode, even if they have physical access, at least not without Apple's help (and even then there's ways of hardening that, but we're still working on the details). And I still don't have to delegate all my security to Apple; I can still use full disk encryption and know that even if they reboot the device to take over the boot process, they won't be able to get at my data.
This is not to say the M1 is a security panacea and the L5 is terrible. They each have their pros and cons. Some people might prefer one, some people might prefer the other. That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion.
For the record - we have some changes for this driver in our downstream tree waiting to get upstreamed (some may need to be reworked though): https://source.puri.sm/Librem5/linux-next/-/commits/next/byz...
I get the frustrations behind it, but its harmful. Its unfair to advocate for others to not use/buy a device because it doesn't fit their perfectionist specifications, while the project made a substantial effort and should be judged on the incremental improvement instead. More so, when they its a unique project which is far ahead of the competition.
What happened though, with regards of that extra layer, is akin to the glue Nvidia uses for their proprietary driver. Its akin to greenwashing. Its dishonest, and unnecessary. Its a marketing ploy. Yes, we should criticize companies for such behavior. No, it does not mean the entire product (or company) is terrible.
However, there are people in the FSF who recognize this. See the comments of Leah Rowe (the Libreboot maintainer) about the problems with the RYF criteria: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-... (read her comments in the libreboot policy she linked to)
I have also criticized the binary nature of RYF certification and suggested that it either needs to move to a category based system: https://forums.puri.sm/t/does-respects-your-freedom-certific... or a number score system: https://forums.puri.sm/t/does-respects-your-freedom-certific...
> That's why we need to educate users about the realities of the devices they choose to purchase, instead of slapping meaningless "RYF" labels on them and discouraging nuanced discussion.
I largely agree that RYF has problems, but it isn't useless, since it does tell people that they can install a new OS or upgrade it without having to deal with proprietary blobs. However, if people want to upgrade the firmware, a RYF device makes that very inconvenient, because you can't just stick the new firmware in the /lib/firmware directory, but have to follow an awkward procedure to upgrade each component's proprietary firmware, and the RYF rules are unclear about whether those upgrades are even allowed. I have written repeatedly to the FSF asking for clarification on whether proprietary firmware can be upgraded under the RYF rules, and I have never received an answer. See: https://forums.puri.sm/t/does-respects-your-freedom-certific...
It's worth mentioning that Purism intends to provide firmware updates for the L5 and has already posted instructions upgrading a couple components: * Texas Instruments TPS65982 USB Type-C and Power Delivery controller: https://source.puri.sm/Librem5/firmware-tps6598x-nonfree * Silicon Labs RS9116 WiFi/Bluetooth: https://source.puri.sm/Librem5/redpine-firmware-nonfree
However, I would agree that the RYF certification isn't useful for distinguishing whether the PinePhone's firmware is more free than the Librem 5's firmware. In fact, it can be argued that the PinePhone has inspired a lot of community work to replace parts of the EG25-G modem's proprietary firmware, so the PinePhone will potentially have a freer modem than the Librem 5.
RYF also has nothing to say about the freeness of your hardware. For example, the MNT Reform provides all its sources for the design of the hardware, so anyone can legally make it, whereas Purism has released the PDF files for the L5's schematics, and the STL files for its case, but won't release the original design files for the boards and case until it recovers its development costs. PINE64 releases the board schematics as PDF files, but they have a normal copyright, so no one can legally reuse or modify them. If you want to do board repair, however, you need to know the placement of each component on the board, and neither Purism nor PINE64 have released board views, whereas board views are leaked for most Apple devices.
> the RYF workaround development was completely unnecessary and just serves to legitimize the FSF, which, indeed, is the root of the problem.
It seems that you want to throw the baby out with the bath water. In my opinion, the basic goals of the FSF need to be supported. The problem is the strategy that the FSF uses to reach those goals and its specific policies. I want to see a world where ordinary people can control the technology that they rely on, rather than technology being used as a means to control people.
As I see it, we got lucky with the x86 architecture, because Intel and AMD used a standard booting procedure which wasn't locked, so it was possible to install our own OS on almost any PC in the past, but as PCs move to ARM, I fear that every company is going to copy Apple in designing their own ARM processors for PCs, which have custom booting procedures. Maybe Qualcomm, Samsung, MediaTek, UNISOC and all the rest who are reportedly designing custom ARM processors (Google, Xiaomi and Oppo) will release their files or share info, but I suspect that many PCs in the future will be like the Apple A-series processors where we can't install Linux.
In my opinion, the best strategy to avoid this dark future is to support the device makers and component makers who support free/open source software, rather than continuing to buy products from companies that don't share our goals. Apple sued Corellium (and thankfully lost in court), which is a good indication of Apple's attitude toward its users. When we buy Apple products, we give more resources to a company that is openly hostile to users being able to control their own hardware.
While I have specific criticisms of the RYF, I want the RYF certification program to be reformed so it is useful in the real world, because I do think that people who care about FOSS should be giving their money to companies that support their goals, because that is the best way to create a sustainable industry in the long term that respects user rights and are willing to work with the community. Giving our money to companies like PINE64, Purism, Lulzbot, OLIMEX, Raptor Systems, Arduino, MNT, etc. helps build up our leverage, because these companies will have more power to make demands of component suppliers.
NXP has positioned itself as the best ARM manufacturer for the Linux community (ahead of Rockchip), whereas I rank Apple as the second worst (although today I would now place it as the third worst ahead of UNISOC and HiSilicon). See: https://forums.puri.sm/t/concerns-about-the-security-risk-of...
I know that the Librem 5 doesn't have great performance compared to a phone based on an A13 or Snapdragon 888 (see my benchmarks: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...), but I bought the phone anyway, because I know that Purism went out of its way to select component manufacturers who support FOSS. NXP makes commits to mainline Linux to support its i.MX processors, and releases documentation to the community without NDA's. Silicon Labs (formerly Redpine Signals) releases the drivers for its WiFi/Bluetooth chips under the GPL 2 and altered its firmware at the request of Purism so it didn't have to load the firmware from the main Linux file system. By giving money to Purism, NXP and Silicon Labs, I'm helping to build up a better supply chain, so there is more hope of getting hardware in the future that respects our digital rights.
x86 situation is actually horrible. Not only there are SMM interrupts that are continuing to execute firmware code outside of OS control, it also has proprietary security processors running signed code (ME/PSP) with potentially unlimited access to main memory. M1 fares much better in category of "amount of proprietary code running that might affect your security": no firmware code running at all on the main CPU after bootloader passes control to the OS, and all coprocessors are safely gated behind IOMMUs.
As for other ARM PC consumer devices, they will probably use whatever Windows requires to boot, which is UEFI + ACPI.
Before anything else, let me say thank you for your work on the M1, because it is essential that we have Linux support for processors even when the device maker is opposed. Considering how many millions of people have bought Apple's M1 devices, Asahi's work is critical because it provides a path for people to discover a freer system when they get disgusted with Apple's bad practices and the restrictions of its "walled garden."
Having said that, I don't think that your criticism of Purism's kernel work is very fair. Purism made its first commit to mainline Linux for the Librem 5 in July 2018 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). Purism submitted the device tree for the Librem 5 DevKit to mainline Linux on June 17, 2019 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), which was 7 months after it started shipping the DevKits in mid-December 2018 (https://puri.sm/posts/2018-devkits-are-shipping/). I can find emails from Purism trying to submit the device tree for the Librem 5 since May 25, 2020 (http://lkml.iu.edu/hypermail/linux/kernel/2005.3/00715.html), which was 7 months after it started shipping on Nov 17, 2019. Since Linux version 4.20, Purism has made roughly 150 commits to mainline Linux to support the Librem 5, whereas System76 has made 13 commits to the Linux kernel (https://blog.system76.com/post/667593198841069568/open-up-co...) and TUXEDO Computers has made one commit (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...), and I can find commits for the rest of Purism’s competitors (PINE64, Juno Computers, Slimbook, ThinkPenguin, F(x)tec, Planet Computers, Hallo Welte, etc.)
You are comparing the work of a company with two kernel developers (Angus Ainslie and Martin Kepplinger) to an entire community working on Linux support for the M1. Purism has only shipped 2600 Librem 5's so far, whereas Apple is shipping roughly 7 million M1 Mac PCs and 15 million M1 iPads every quarter. If you are going to brag about getting M1 support into mainline Linux within 4 months of the release of the M1, consider the fact that the first commits to mainline Linux for the i.MX 8M processors were submitted just 8 days after NXP announced that it had started volume shipping of the processors (https://www.pengutronix.de/en/blog/2018-01-17-first-mx8m-mai...). This was possible because NXP shipped early versions of the processor to many companies and has released 7000 pages of documentation on the processor, plus NXP pays several of its own employees to work on getting the i.MX 8M supported in mainline Linux. It does make a huge difference whether a company decides to collaborate with the Linux community or not.
You also have to keep in mind that Apple has shipped 2 billion devices with A-series processors that never got mainline Linux support, so we got really lucky that 1) Corellium managed to figure out how to run Linux on the M1 and 2) Apple decided to not block the use of custom kernels with the M1. Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017 (https://craft.co/corellium) and company's blog makes clear that it was its previous work on the A-series (boot sequence, PCIe and USB controller) which helped it get Linux support working so fast on the M1 (https://www.corellium.com/blog/linux-m1), so Corellium wasn't starting from scratch in figuring out how the M.1 works.
By the way, it's worth pointing out that most of Purism's dev work hasn't focused on the kernel, but has instead focused on creating the Phosh mobile environment on top of GTK/GNOME, and Purism has created about a quarter million lines of new code so far (https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr...), and 169.4k of that code (libhandy, libadwaita, Chats and Calls) has been incorporated as official GNOME projects. Purism purposely designed the L5's software to work as a thin overlay on top of an existing desktop Linux stack, so PureOS/Phosh has done a better job than Meego, Sailfish OS, Firefox OS, Ubuntu Touch and WebOS at making a version of mobile Linux which is compatible with the larger Linux ecosystem. Purism commits upstream as much as possible to projects like Linux, wlroots, ModemManager, Geoclue, GTK, GNOME and about 20 different GTK/GNOME apps (Nautilus, gEdit, GNOME Calendar, CNOME Contacts, GNOME Clock, etc.) so that the L5 will be easier to maintain and be able to run on other Linux distros (postmarketOS, Mobian, Ubuntu Touch, etc.).
> To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might)
The i.MX 8M does have a secure boot option, but Purism isn't going to use it because it isn't controllable by the user. Purism's Kyle Rankin commented that they are discussing how to implement a user-verifiable boot procedure, like they have with PureBoot + Librem Key on their laptops, but Purism has a lot of other stuff on its plate (like suspend to RAM, camera auto-focus, encryption with keys from the OpenPGP card, etc.) which is higher priority, so I doubt that it will be implemented soon. The Ubuntu Touch port should have secure boot, but UBports has put their porting of the L5 on hold to focus on the PinePhone and PineTab, so I assume that will also take a while.
More like deliberately modified their design to allow it.
>Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017
I don't think Corellium did have much effect on the Asahi upstreaming effort, they just posted haphazardly patched up kernel tree which they were using for validation of their virtualization platform. Majority of their patches weren't suitable for upstream submission.
RYF certification is absolutely meaningless, both from the freedom and security/privacy perspectives. It is actually actively harmful to freedom, as it encourages manufacturers to hide blobs to get through its backdoors (ROM blobs are OK, RAM blobs are not), when doing the opposite is actually more accountable and open, and allows for user-controlled replacement of blobs with free versions in the future.
Also, Stallman had personally said he wouldn't give the Novena open hardware laptop RYF certification unless they permanently fused off the GPU, "because otherwise users might be tempted to install the (optional, not distributed with the product or endorsed in any way) GPU blobs". Literally the same product segmentation nonsense we're bashing Intel for here. This was before open drivers became available, which they eventually did. Imagine how wrong the situation would've been if bunnie, the creator of Novena, had actually listened to this; "RYF" certified Novena owners would own crippled machines unable to use 3D acceleration, while the rest would own machines capable of running a 100% libre desktop including 3D acceleration.
> Libreboot disagrees with that
You do realize that that post is Leah politely saying that RYF sucks and is completely broken, and she's given up on strict compliance, right? FSF policy is indeed that you shouldn't upgrade your microcode (see e.g. endorsing linux-libre, which censors kernel messages telling you about important microcode updates).
This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for users, and also a net security negative. This whole rhetoric that updatability matters, or that somehow lack of source code means "only the manufacturer can update it" and that somehow "makes things less free for users" needs to stop. Users are still in control of updates, the thing isn't magically phoning home (corner cases of stuff with network access notwithstanding). Having access to the blob is a net positive on all fronts for users. This whole policy keeps trying to use this excuse as a rationale, but the reality is the only thing it achieves is convincing people that they aren't running blobs at all by condoning devices where the blobs aren't evident to users because they're not in their filesystem.
This was all brought to its logical extreme of silliness with the Librem 5, which actively engineered an obfuscation mechanism for their RAM training blob to put itself in compliance with RYF, for absolutely no benefit to users: it's still running the same blob as it would've otherwise, and it's still updatable (you can even ignore the entire obfuscation and just flash your own bootloader that does it the normal way).
So we both say the same thing with different words. I agree, which is why there is a call to FSF for change.
Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
I thought you were saying that hardware is whatever "cannot be updated". That's the argument the FSF uses to say ROM firmware is OK because it's not software. I'm saying that's not okay, because updatability is a plus, not a minus, and ROMs are still software.
> Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
The obfuscation in the Librem 5 did absolutely nothing to isolate the proprietary blob in any way, shape, or form. It would always run on a dedicated CPU, from the get-go (and that CPU is part of the RAM controller, so it is a security risk for the entire system either way). They added a third CPU in the loop to load the blob, because somehow touching the blob from the main CPU gives it the digital equivalent of cooties in the FSF's view, but adding this extra step of indirection makes it all OK. And then they put the blob in a separate Flash memory so it wouldn't live in the same flash as the main open firmware, because that somehow helps freedom too? Seriously, that whole story is just utterly stupid no matter which way you look at it.
Yes, I'm saying that. But if you intentionally prevent users from updating it, then it does not turn software into hardware in my opinion.
Do you have any link saying that the blobs are still being executed on the main CPU after the RAM training is finished? Upd: you replied here: https://news.ycombinator.com/item?id=29842166.
There is a distinction between blob 'is in ROM and cannot be updated', 'is in EPROM and might be updated', and 'it is in RAM and must be provided at boot'.
While one can argue about the second case, the third case is problematic for practical and legal reasons, as handling (using and distributing) requires accepting licence of the firmware, which affects distribution infrastructure of free Linux distributions. Some firmwares also do not allow redistributing, so they have to be downloaded from vendor website, which further complicates practical and legal matters and have privacy issues.
The second case (it is in EPROM nad might be updated) does not have such effect directly, but leads to it indirectly, by allowing vendors to depend on cheap post-purchase fixes by firmware update, so they can offer less tested products, where firmware update is practically necessary due to original firmware being buggy, so essentially moving to the third case.
i just can't wrap my hands around macOS and I used to work at apple. I'm just so used to linux for everything.
- forbidding motherboard manufacturers to implement backward compatibility
- PCIE 4 and 'PCI Express Resizable BAR' CPU features linked to the price of northbridge
AMD supports ECC on their consumer chips, but without Intel support it's never taken off and some motherboards don't support it, or if they do it's not clear in the documentation. I do use ECC RAM on my Threadripper machine and it does work, but I had to look for third party info on whether it would and dig around DMI and EDAC info to convince myself it was really on. It also makes it safer to overclock RAM since you get warnings when you're pushing things too far, before outright failures. And it helps with Rowhammer mitigation.
Apple M1s don't do ECC in the memory controller as far as I can tell, but at least they have a good excuse: you can't sensibly do ECC with 16-bit LPDDR RAM channels. There's no such excuse for 64/72-bit DIMM modules. I do hope we work out a way to make ECC available on mobile/LPDDR architectures in the future, though. Probably with something like in-RAM-die ECC (which for all I know might already be a thing on M1s; we don't have all the details).
Intel has offered ECC support in a lot of their low-end i3 parts for a long time. They’re popular for budget server builds for this reason.
The real reason people don’t use ECC is because they don’t like paying extra for consumer builds. That’s all. ECC requires more chips, more traces, and more expense. Consumers can’t tell if there’s a benefit, so they skip it.
> AMD supports ECC on their consumer chips, but without Intel support it's never taken off
You’re blaming Intel’s CPU lineup for people not using ECC RAM on their AMD builds?
Let’s be honest: People aren’t interested in ECC RAM for the average build. I use ECC in my servers and workstations, but I also accept that I’m not the norm.
I'm blaming the decade+ of Intel dominance for killing any chance of ECC becoming popular in non-server environments, just as RAM density was reaching the point where it is absolutely essential for reliability.
> The real reason people don’t use ECC is because they don’t like paying extra for consumer builds. That’s all. ECC requires more chips, more traces, and more expense. Consumers can’t tell if there’s a benefit, so they skip it.
Motherboard traces are ~free and the feature is in the die already, so it requires zero expense to offer it to consumers. Intel chose to artificially cripple their chips to remove that option. Yes, I know there are a few oddball lines where they did offer it. They should have offered it across the board from the get go, seeing as they were selling the same dies with ECC for workstation use.
OTOH, it shouldn't be significantly more expensive. It should be ~9/8 the cost of regular memory. It's just one extra chip for every 8. Nothing more.
(in-band ECC is present on Elkhart Lake Atoms and on Tegra Xavier for example)
I disagree. AMD has offered ECC support for a while and it’s not catching on. It doesn’t make sense to blame this on Intel.
> Motherboard traces are ~free and the feature is in the die already, so it requires zero expense to offer it to consumers.
Yet it’s missing from a substantial number of AMD boards, despite being supported. You have to specifically confirm the motherboard added those traces before buying it.
Traces aren’t entirely free. Modern boards are densely packed and manufacturers aren’t interested in spending extra time on routing for a feature that consumers aren’t interested in anyway.
Or they just don't care because it's not already popular and unbuffered ECC RAM isn't even particularly widely available. The delta design cost of routing another 8 data lines per DIMM channel is tiny. Especially on ATX boards and other larger formats. I could see some crazy packed mini-ITX layout where this might be a bit harder, but definitely not in the normal cases.
(I've routed a rather dense 4-layer BGA credit card sized board; not exactly a motherboard, but I do have a bit of experience with this subject. It was definitely denser than a typical ATX board per layer.)
Every time I've gone looking for unbuffered ECC RAM over the past three or five years, I've had no trouble finding it. In my experience, the trick is to shop for "server" RAM, rather than "desktop" RAM.
Are there speeds or capacities here that you'd particularly like to see that aren't present? <https://nemixram.com/server-memory/ecc-udimm/>
I've been quite satisfied with the three orders that I've placed with Nemix. I see no indication that they _don't_ ship to Japan, and indications that they _do_ ship internationally... so consider purchasing from them next time you have a need for such memory.
Or, hell, I'd be _shocked_ if there wasn't a company in JP or or KR or CN that also does what Nemix does (that is, yank RAM from decommissioned servers, test it, and sell the stuff that's solid).
And, with Ryzen (and Ryzen Threadripper) becoming ever-more popular, I would expect ECC RAM to continue to drop in price when compared to non-ECC RAM. (But, let's be real here, when you spread the price out over five or ten years, it's _totally_ worth it to have RAM you can rely on.)
It does make sense. Imagine if only 50% of web browsers supported a feature, would you implement it in your website?
Point being, the low market share of ECC-compatible setups means that the market demand for ECC is low, which means that the selection is low, which means the prices are higher than they could be. So yes, absolutely Intel has contributed massively to the issue.
Intel removed ECC support in the 10th gen so you have to go for Xeon nowadays.
Yes. ECC was standard on first IBM PC 5150, on PS/2 line, on pretty much all 286 clones etc. Intel killed ECC on the desktop when moving to Pentium, prior to that all of their chipset products (486) supported it. 1995 artificial market segmentation shenanigans https://www.pctechguide.com/chipsets/intels-triton-chipsets-...
In the absolute the cost of ECC everywhere would not be substantially greater than the prices we have now without. The current ECC prices are high because it is not broadly used, and not really the inverse. Consumer skip it because it is fucking hard to get ECC enable parts for S SKUs (or H / U) in the current situation, while there are plenty of non-ECC vendors and resellers, and something like at least 3 times the number of SKUs. And consumers have not been informed they are buying unreliable shit.
I think computers are now so important to our life, we need to start regulating them like we do cars.
Start seriously slapping companies that deliberately or negligently release equipment with obsolete kernels and security holes, mandate ECC like we mandate ABS, mandate part avaliability for 10 years like we do with cars, etc.
Every day we let this this slide, thousands of people loose precious data and number of 'smart' toasters mining crypto increases.
Think about how many laptops ship with Wi-Fi whitelists with the excuse of "FCC certification". It doesn't matter that the FCC doesn't actually prohibit users from swapping out Wi-Fi cards; manufacturers will do it anyway.
And not just storage - the main memory bus is the only data bus in a modern computer that doesn't use some form of error correction or detection. Even USB 1.0 has a checksum. So everywhere else we use ECC/FEC or at least a checksum, be it PCIe, SATA, USB, all storage devices as you mentioned rely heavily on FEC, all CPU caches use ECC. Except the main memory and its bus. Where all data is moved through (eventually). D'uh.
[0] https://www.revk.uk/2017/12/its-official-adsl-works-over-wet...
Not literally wet string, but definitely low tech. ADSL is special though, not many technologies can literally run over wet string :-)
Of course we do: workstations.
It's cheaper, that's why it isn't everywhere.
And now the next desktop consumer upgrade I purchase will be AMD and will have ECC (well... unless it's way more expensive).
I put it in an Intel-branded motherboard as well, and that turned out to be one of the few motherboards I've had that failed prematurely.
Since then, the only Intels I've bought since then have been used ThinkPads.
The efficiency cores don’t have AVX-512 because they’re low power, simplified cores.
This mod required disabling the efficiency cores, reducing core count anyway. It wasn’t actually a free upgrade.
> I much prefer AMD's strategy of segmenting just by speed and number of cores
I’ve been using ECC RAM with AMD consumer parts, but it’s not all smooth sailing. The ECC support in their consumer parts isn’t officially supported, so it has been extremely difficult to determine if it’s even working at all. There are long forum threads where many people have tried to confirm it with mixed results. AMD may unofficially leave these features in place, but it turns out unofficial support isn’t all that straightforward.
If you run Linux, you can use dmidecode and the EDAC driver to confirm if you have ECC enabled.
I know the explanation in some cases were that they didn't pass QC, but I also never came across stories of widespread problems when these cores were reenabled by end users.
If Intel is playing games here, I'm not sure they're unique to Intel.
[0] https://www.techradar.com/news/computing-components/processo...
[1] partial list of prior unlockable AMD chips: https://docs.google.com/spreadsheets/d/19Ms49ip5PBB7nYnf5urx...
The reason is I got tired of dealing with Ubuntu being unable to be installed in my AMD Ryzen 2500U.
Yes, even with the latest version using the latest kernel, and my last attempt to install it was a few days ago in 2022.
Last time I mentioned this issue about AMD in this forum I was downvoted, but I don't care, I am writing now this comment from a nice laptop, and I'm back in Linux again, so I am happy with this decision.
My point is: yes, AMD market segmentation is better, and I wish them the best. But for my particular use case: Windows is not enough, and I require the machine to work in Linux, therefore Intel is a must.
Switched to AMD for the first time in my life, no regrets so far.
mitigations=off
You do not need to be a nation state to fall victim to sophisticated attacks. Most attacks nowadays are performed by bots indiscriminately blasting exploits to anything they can reach.
Even if state actors were the only ones capable of exploiting Spectre/Meltdown, you could still end up being collateral damage.
Infecting employees at their home computers and then spreading via USB/shared files to work computers is nothing new either.
Spectre only works in the same address space, which is why chrome uses so many processes.
It was already thought that this would become a problem to worry about at smaller process nodes, but does AVX-512 on Alder Lake push voltage and heat enough that it is an issue already?
>Electromigration is the movement of atoms based on the flow of current through a material. If the current density is high enough, the heat dissipated within the material will repeatedly break atoms from the structure and move them. This will create both ‘vacancies’ and ‘deposits’. The vacancies can grow and eventually break circuit connections resulting in open-circuits, while the deposits can grow and eventually close circuit connections resulting in short-circuit.
https://www.synopsys.com/glossary/what-is-electromigration.h...
>Aging Problems At 5nm And Below
https://semiengineering.com/aging-problems-at-5nm-and-below/
(Citation needed for my initial claim that the perception of the performance hit exists within that population.)
You can apply them or don't at your own discretion.
The problem is knowing which particular update includes the change.
During boot there's usually no network connectivity, so how would the BIOS even know of an update, let alone acquire it?
You update your BIOS to get better DDR5 compatibility, but the new BIOS will also include a microcode update.
The FIT is still updated externally (e.g. by the OS) and doesn't magically fill itself with new microcode.
The BIOS holds a copy of the microcode and this can be upgraded by upgrading the BIOS/EFI (bundled with BIOS updates). The same for the OS.
On boot the BIOS loads it's update first, then the OS, provided each is newer than the currently loaded microcode.
So the idea is that if you don't like this update, you need to prevent your BIOS from updating (or downgrade it), and then also configure Linux to ether not upload it's microcode, or load a specific one.
Point still stands: no one forces you to upgrade your BIOS (unless there's problems) and even then, patching the BIOS upgrade itself is still an option.
So it remains under user control.
In my case I managed to get it to work with some random vendor tools run from DOS, which bypassed the EFI flash subsystem. Definitely not a pleasant experience.
Intel/AMD(though i can't remember AMD doing this in the last 5+ years) forcing motherboard vendors to effectively brick and disable features from consumers sounds like shouldn't be possible. You don't buy the CPU as a subscription to compute, you buy it as a product.
I absolutely destest FP benchmarks, and I realize other people care deeply. I just think AVX512 is exactly the wrong thing to do. It’s a pet peeve of mine. It’s a prime example of something Intel has done wrong, partly by just increasing the fragmentation of the market." Linus T
It's like asking a 3D game programmer their opinion about FPGAs.
It wasn’t a net win for the average person. I doubt many people would ever do this.
It's almost like Intel doesn't want people to use that feature
Such P-core-only chips are attractive to Linux users. Intel Thread Director, their Alder Lake schedule software, does not work as well on Linux as it does on Windows. It has a tendency to schedule processes on the E cores even when P cores are available, which is bad for performance.
There is significant overlap between users interested in AVX-512 and users interested in Linux performance, making the mid-range Alder Lake chips especially appealing to this group. Unfortunately they top out at 6 cores with no ECC, so it's not a perfect match.
There might be gazillions of reason why this was done.
If they do then this is indeed fraud.
They can always claim that those were engineering samples and not meant to be tested, but, I think they knew.
But: that's assuming a lot. It's possible that the ES chips sent to reviewers also had AVX-512 disabled, and that benchmarks did not make use of the instruction anyway.
No, because half the cores on those don't even have AVX-512 in the first place. (to enable AVX-512, you have to disable all the eCores)
As such, running those systems with AVX-512 turned on was academic, but not practically used.
It's like buying a car with an advertised speed limiter of 155mph, then finding that actually it can go 170mph, and then the manufacturer fixes the speed limiter with a software update. Yes we know the car could go faster, but the speed limited version is the one that was actually advertised.
That's not a fix. That's a disabling. A fix repairs something.
Besides the obvious benefit of first having benchmarks out there claiming these chips are better than they really are. So this change just benefits Intel, and nobody else. If it would be a fix then it would be that something that was advertised did not work, and now it does.
If people depend on functionality that is explicitly unsupported then I don't know what to say other than that I don't see how that's Intel's responsibility. If you buy a CPU that doesn't support AVX-512 instructions in order to use AVX-512 instructions then ...I think you're the one who is wrong here.
To go back to my car analogy - if you buy a car that isn't type approved for towing, and yet you install a tow bar anyway, you can't complain to the manufacturer if stuff breaks.
>>Besides the obvious benefit of first having benchmarks out there claiming these chips are better than they really are
Are any of the published benchmarks using AVX-512 instructions that were used by Intel in advertising, and were those in fact available at the time when the benchmarks were ran?
>>If it would be a fix then it would be that something that was advertised did not work, and now it does
Those CPUs were not compliant with their own published spec, now they are - it is absolutely a fix.
That may apply to every change, including things everybody agrees on to be bug fixes. If, for example, you improve the number of correctly returned bits for computing sin, that can break programs, for example games that want to keep world models in exact sync across systems.
From what I read here, intel didn’t advertise this feature and it wasn’t easily discovered. If so, I don’t think customers have any claim against Intel for the CPUs.
_If_ motherboard vendors advertised/promoted it (could be as simple as blogging about it), I would think people who bought a motherboard because it allows activating this feature will have a case against them (in the EU and possibly elsewhere, the seller is responsible for the product being fit for purpose, not the manufacturer, so it would be the seller, but let’s ignore that)
Legally, there also is the issue who applies that update. From what I read, that’s the motherboard. Here again, I would say that, if customers have a case, it would be against whomever sold them the motherboard (e.g. if that silently applies the update) I don’t see any indication that Intel, as a CPU manufacturer, forces existing customers to install this.
When a company announces with years in advance a new product (e.g. Alder Lake), that is the replacement for their previous product (i.e. Rocket Lake & Tiger Lake) and in that series of products the most valuable feature is backward software compatibility and the new product will no longer have this feature, one would expect that the company should publicize vigorously the fact that the replacement product will not match the features of the replaced products.
Like, my sister bought the new M1 MacBook Air, only to discover that it doesn't support dual external screens - while her previous Air did. So there was absolutely an expectation there that any new MacBook Air would also support dual screens, right?
But, at the end of the day - it is mentioned in the spec sheet. She could have checked. Just assuming that a feature is there is not enough. What's more - if dual screens worked originally, and then they stopped working after an update - that wouldn't be a bait and switch either, it would be a fix to bring the computer back in line with its spec.
And yes, I agree that it would suck.
But what Intel is doing here is disabling existing silicon that exists and works.
For example, it's known that AVX-512 is power hungry and significantly increases TDP (heat). Do all Alder Lake based products have the thermal headroom? If CPUs operate outside of the envelope communicated by Intel, they may not be entirely stable, and parts could fail earlier than expected.
While it cannot be said that Intel advertised AVX-512 for Alder Lake, at all previous disclosures it was said that the Golden Cove cores have AVX-512 and the Gracemont cores do not have it.
It was clearly said that in hybrid configurations AVX-512 will be disabled, because for Microsoft it is a too difficult task to implement scheduling on a system with heterogeneous cores.
Whether AVX-512 can be enabled by disabling the Gracemont cores was not said, but everybody interpreted that saying nothing about this means that it will be possible to enable AVX-512, because Alder Lake is a replacement for Rocket Lake and Tiger Lake, both of which have AVX-512.
This is one of a very few cases, if not the only case, when Intel replaced a CPU product without preserving backward software compatibility.
If this was their intention from the beginning, then they certainly should have said it much earlier, not just immediately prior to launch.
Reading up on it, I was under the impression that's exactly how it worked, no? If you disable the efficiency cores in BIOS, the enable AVX-512 option would appear on selected few motherboards. You can't have all cores enabled and keep AVX-512 enabled at the same time.
Now however, Intel has issued a BIOS update that no longer allows enabling AVX-512 when the Gracemont cores are disabled.
The motherboards produced from now on will have the new BIOS version.
Keeping the original BIOS on the existing Alder Lake motherboards is not a good choice, because the new BIOS version also improves stability in certain memory configurations.
But it's not like this changes anything legally. Products get worse due to software changes all the time (especially through cloud services shutting down) and as far as I know there haven't been any successful lawsuits about it.
More like you buy a car without paying for a satellite radio(or that feature isn't advertised and isn't in the spec sheet), and then that feature gets removed next time you bring the car in for service. That is absolutely fine.
Let me play a devil's advocate here - what if using the feature actually damages the processor after a while? AVX instructions always generate a tonne of heat. Maybe that's the reason why it was meant to be unsupported in the first place. Should Intel be allowed to fix the CPU and bring it in line with spec, or is that "making the product less useful"?
Edit: also - Intel isn't forcing anyone to install this BIOS update. If you want to keep it with AVX instructions available, at the cost of disabling all efficiency cores - sure, keep it that way.
Yes it would.
> what if using the feature actually damages the processor after a while?
Tell the owners this, and let them choose whether or not to take that risk.
> Intel isn't forcing anyone to install this BIOS update.
But then you'll be forever vulnerable to whatever the next variant of Spectre is. You can't cherry pick just the good parts of the update while excluding the bad parts.