I’m not surprised. A lot of people were burned last year when their entire CPU downclocked as soon as one application started using AVX-512. That killed all interest even before Alder Lake.
> Today, only benchmarks and HPC workloads make use of it.
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).
> According to the sources, users would need to disable E-cores
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.
Although this comes up a half dozen times every time hybrid CPUs and AVX-512 is mentioned, it is not so simple when considering existing x86 software.
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.
Enabling AVX-512 also requires the efficiency cores to be disabled. A lot of people are getting upset about this, but it wasn’t really a free benefit for anyone except those with very specific AVX-512 workloads that didn’t benefit from the extra cores.
Technically Intel actually did the things Linus asked for and did AVX-512 as well (on the server at least): The Golden Cove cores are extremely wide and brought a big single thread performance boost.
If all of this was planned (and I’m not saying it is), that would have been very clever. It would work like this:
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.
> 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.
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.
> 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.
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.
> 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.
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.
What benchmarks? Not a lot of real programs actually use AVX512, and a lot of the ones that did discovered that it made performance worse, so they stopped.
(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.
> What benchmarks? Not a lot of real programs actually use AVX512, and a lot of the ones that did discovered that it made performance worse, so they stopped.
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.
It's worth saying that in my life as and academic, the only program I've ever used that has commonly benefited from avx-512 in my work is Gromacs. Gromacs is a molecular dynamics program that creates beautifully graphical simulations and often appears as-is in benchmarks (the so-called ns-per-day metric). Although almost indescribably complex it's also fundamentally strangely straightforward in what it does, and avx-512 does indeed make it significantly faster.
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.
> 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.
Wouldn't it be entirely up to the OS to decide on what core(s) a thread will run?
Theoretically, the E core can raise a #UD (undefined instruction) exception that the OS would trap (which already happens if the CPU doesn’t have AVX-512). The OS could then detect that the offending instruction is from the AVX-512 set, and move it to a P core. It could even set a flag on the thread to force it to use P cores.
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.
> If your code benefits from AVX-512, it'll probably benefit from turning off the efficiency cores too.
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.
There have been reports that it was possible to enable AVX512 on the big cores with the little ones enabled [0] by toggling some bits in the MSR.
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.
I don't see how "poorly parallelized" is relevant compared with, say, a decent OpenMP BLAS which is likely to benefit from any reduced power consumption that allows a faster clock. In general on compute nodes it's worth turning off cores dynamically which aren't being used by jobs, like on a half-full node.
All companies deserve skepticism, to be clear. AMD have their management engine too. As far as I'm concerned the only reason why AMD's ME isn't as developed as Intel's is because their products have been such a joke leading up to Zen that no one with men in suits bothered asking them for the capabilites, or something like that.
I've voiced this before but I think AVX-512 is completely irrelevant in the consumer space (which imho makes titles like "Intel artificially slows 12th gen down" incredulous). Even for commercial applications - sure there are some things that benefit from it. On the other hand, I work in HPC and even in (commercial, not nuke simulations or whatever the nuke powers do with their supercomputers) HPC applications AVX-512 is rarely used.
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.
It is irrelevant because it is not wide-spread.
AVX-512 is much nicer to program than nay previous Intel's vector instructions.
It will be relevant if programmer could assume, that 50% of her auditory has CPU with AVX-512.
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.
> I've voiced this before but I think AVX-512 is completely irrelevant in the consumer spac
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.
> Don’t forget that reviewers made a huge deal out of the fact that CPUs downclock themselves when running AVX instructions.
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...
To me, it does seem really weird that they opted to downclock the entire CPU rather than increase the latency of the instructions that caused overheating. That feels like it would have been a much less disruptive solution that would work strictly better.
If you increase latency, the ROB fills up quicker, and could get full which would back up the pipe. It makes sense why they’d choose to use the default “downclock on overheat” rather than add more circuitry to deal with that specific issue.
When the first AVX instruction is run after a long period of no AVX, something like this does happen: the dispatch of instructions is throttled to 1 out of 4 cycles while some AVX instruction is in the scheduler (this applies to all instructions, not just AVX).
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).
BCD instructions were ubiquitous from the 8086 to the last x86-32 processor, but were so rarely used they weren't extended to 64-bits on x86-64 even though 'backward compatibility' was considered critical. So...probably more complicated.
I could absolutely make a good use of AVX-512 for a lot of applications, including consumer space. It's even better than AVX2 when it comes to flexibility, and of course, it's double width.
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.
Thing is, you probably wouldn't use most of the AVX-512 instructions even provided. Some of them are ridiculously niche to the point I'd be really curious how anyone has actually used them.
> 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.
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.
Huh, TIL. Would you say that most AVX-512 instructions are then useful in such applications? Given Intel's history of inventing less than useful things (segmented memory, for example) I figured AVX-512 was mostly useless.
Well, segmented memory was a pain in the butt but was useful at the time -- not to mention _way_ less of a pain than bank-switched memory.
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.
> On the other hand, I work in HPC and even in (commercial, not nuke simulations or whatever the nuke powers do with their supercomputers) HPC applications AVX-512 is rarely used.
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.
As ever, it depends, probably on whether your code is dominated by matrix-matrix linear algebra. BLIS DGEMM on my SKX workstation runs at ~88GF, or ~48 if I restrict it to using the haswell configuration (somewhat different on a typical compute node).
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.
Sure, there are gains if the code is right and the density of AVX instructions is high enough. In most cases that’s not really the case as these dense matrix multiplications are part of a larger algorithm, which includes things like time integration and some calculations that are not straightforward matrix products. The logic is also more complex. The state changes and reduced frequency caused by AVX-512 make the tradeoff difficult.
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.
I agree it's difficult. Do people ever just turn off the AVX512 in their BLAS, FFT, etc. because of throttling? I've never seen that, but then I usually don't see people measure anything usefully, if they even know the effect.
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.
Glibc has this strange attraction to having SIMD everything for SIMD friendly functions even though average length to these functions is generally less than 16
> No one claimed it was there, would work, would be stable or anything to that tune.
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.
Intel explicitly states which instructions sets each processor supports. They don’t list every random register or instruction. Those are captured in the detailed documents.
> What matters is whether consumers were defrauded by seeing a feature they bought
Nobody was defrauded.
The CPU never advertised AVX-512 support. You could never enable it “for free”. You had to disable the efficiency cores and use a BIOS where the manufacturers simply forgot to turn it off.
There is no fraud here and it’s weird to claim as much.
Many features of products aren't advertised explicitly. You don't expect those to be disabled, however, if part of the reason you purchased it was because you found out it was there.
I can see Intel's rationale if it were never promised, but the timing of the removal of the feature is suspect. If Intel is doing this because it sees some level of future chip sales being negatively impacted by a feature that is in the chip that they previously gave customers access to, then they should be held accountable in my opinion. If nothing else people burned by this can chalk another one up to Intel's misguided sales team. It's as if Intel is asking for this sort of attention lately.
* 1. Very few “evil schemes” exist in reality because people aren’t all that clever (and all that evil)*
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.
I'll be honest, this looks to be a simple mistake. Cutting AVX-512 literally (meaning in hardware) requires actual staff doing that cut plus it'll increase turnaround times, plus the efficiency cores don't have it. Unlike "let's bin perfectly functional processors into a lower-cored product", this is economically not logical for Intel, which often is the closest from the truth.
And if it wasn't designed to be "blowed up" in the first place, in the hopes that the E-cores do have AVX-512? In that case, it's a literal cut and not simply blowing the fuse.
They always have fuses for this stuff. They have fuses for everything. Modern silicon has piles and piles of chicken bits and fuses to make sure they cover all their bases. There is zero chance they didn't have a hard fuse to disable a known controversial/segmentable feature like AVX-512.
If it wasn't desigend to be disabled it would be buried under multiple and multiple metal layers. You can't "cut" it like a wire. Metal layers run all over the place [1].
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.
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.
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.
Soon enough most motherboard BIOSes will come already with the new microcode disabling AVX-512, so you also have to hunt down an old-stock motherboard.
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.
>though, because that's not possible in their heterogeneous architecture
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.
Fair point, but again most Windows programs aren't designed with heterogeneous CPUs in mind, so probably they don't want to deal with the headaches, plus the space used for AVX-512 (note that it's now in microcode) can be repurposed for more important tasks.
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).
It's not in microcode, they're just disabling it in a microcode update. Microcode updates aren't replacements for microcode either, they're patches. The vast majority of microcode is in ROM and can never be changed wholesale; updates can just patch in hooks and change certain things, limited by the number of patch slots available. Doing this does not "free up" any microcode. It's purely disabling a feature, there is absolutely nothing to be gained in return.
This somewhat reminds of the following software optimization procedure:
- 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)
Some parts of the game would probably benefit a bit from 512 (also remember that it isn't just wider, it adds a lot of new operations entirely), but there simply isn't enough parallelism in the main loop of a game to make all that much difference.
For games generally those parts can be shifted to the GPU because they feed the rendering pipeline anyway. Doing so has other benefits of lowering latency for that data to be picked up by the graphics bits already there etc. Also the clock speed penalty for AVX512 is pretty steep so unless you're going to do a lot of AVX512 it really doesn't make sense either. Games generally aren't using double precision either which is the AVX512 bread and butter. To make it more fun even if they were... a 4x4 matrix is composed of 256bit elements so the vast majority of register usage wouldn't be 512 bit anyway. The main benefit would be the new instructions more than the register width.
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.
AVX-512 is so useful in benchmarks that sites like Anandtech intentionally build their benchmarks without it, because the presence of AVX-512 spoils the whole horse race narrative they are trying to sell.
> Very few “evil schemes” exist in reality because people aren’t all that clever (and all that evil).
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.
This makes no sense. There are plenty of secrets and schemes out there. Often it's only necessary to keep a secret in the present. If it comes out years later, often people just ignore it.
> 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.
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.
Even if a reviewers test suite does benefit from AVX512, it's unlikely that their Alder Lake reviews would actually be swung by it because AVX512 was always disabled in the standard configuration with all of the CPU cores enabled. Enabling AVX512 required disabling the efficiency cores altogether, and running with just the performance cores.
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.
I don't think that anyone who cares about specific CPU features would not know that it shouldn't work and therefore wouldn't risk getting it removed later
Everyone else would not know that this might have a performance impact.
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.
It doesn't provide any advantages because there is no install base, so desktop software doesn't utilize it. It's just a wider SIMD instruction set, and I'm confused why people relegate it to HPC only category.
AFAIK it downclocks the CPU, even if the AVX512 instructions are only a tiny fraction of instructions. So you only benefit from AVX512 if you use it enough. While 128 bit SIMD give you a speedup if you use it for a few functions that need it, without slowing down the rest of your code or even unrelated applications.
In heavily vectorized applications you still get a sizable speed up over AVX2, e.g. in tasks like video encoding. In mixed/real-time applications this issue could be solved by dedicating/pinning a thread with the AVX-512 payload to a core, automatically or manually. Not sure if such policies have been implemented in practice.
That was before Ice Lake, where it had a very decent performance (just downclocking 10%) and then on Rocket Lake it didn't even downclock [0]. But the thing that stuck in our collective mind was that "it's bad because it downclocks". And seeing the RKL numbers, which are new to me (I had only read de Ice Lake numbers back in 2020) it wasn't even 14nm's fault, just an implementation issue which Intel eventually worked out.
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.
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.
I was commenting on the fact that people stuck with the idea that "AVX512 is bad because it downclocks". As for turning off the E-cores, yes, it's a tradeoff that you have to consider if it's worth or not for your use case, and probably for most use cases it won't make sense.
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.
Stuff like this is why I plan to never buy Intel ever again. I always disliked Intel's strategy for market segmentation by disabling specific instructions, I much prefer AMD's strategy of segmenting just by speed and number of cores. It is really annoying that with Intel you can't run the same program on the server and on your desktop, it makes development and testing a huge pain.
Don't forget it's not just instruction sets; Intel is the reason we don't have ECC RAM on desktops. Every other high density storage technology has used error correction for a decade or two, but we're still sitting here pretending we can have 512 billion bits of perfect memory sitting around that will never go wrong, because Intel fuse it off on desktop chips. I guess only servers need to be reliable.
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).
> Don't forget it's not just instruction sets; Intel is the reason we don't have ECC RAM on desktops. Every other high density storage technology has used error correction for a decade or two, but we're still sitting here pretending we can have 512 billion bits of perfect memory sitting around that will never go wrong, because Intel fuse it off on desktop chips. I guess only servers need to be reliable.
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.
Yup. PCIe will practically run over wet string, thanks to error detection and retransmits and other reasons, but try having a marginal DRAM bus and see how much fun that is...
My comment was actually a self quote from a talk I gave about PS4 hacking where I described that PCIe will happily run over bare soldered wires without much care for signal integrity, at least over short distances (unlike what you might expect of a high-speed bus like that) :)
Not literally wet string, but definitely low tech. ADSL is special though, not many technologies can literally run over wet string :-)
> Intel is the reason we don't have ECC RAM on desktops.
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.
> You’re blaming Intel’s CPU lineup for people not using ECC RAM on their AMD builds?
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.
> I'm blaming the decade+ of Intel dominance for killing any chance of ECC becoming popular in non-server environments
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.
> 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.)
> ...unbuffered ECC RAM isn't even particularly widely available.
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.
It's available, but not nearly as widely, and even less so at reasonable prices. Last time I had to buy ECC RAM over here in Japan, I had to go to a niche webshop to get a decent price on the capacity I was interested in. For every other PC part I'd just use Amazon and get it delivered next day, usually at the market lowest price or almost.
> Last time I had to buy ECC RAM over here in Japan, I had to go to a niche webshop to get a decent price on the capacity I was interested in.
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.)
> 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.
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.
Actually less, because you only need the additional memory chip and associated trace layouting, not any additional PCB manufacturing cost (beyond miniscule yield impact of the additional traces) and no significant added distribution cost (packaging, shipping weight, etc.).
>You’re blaming Intel’s CPU lineup for people not using ECC RAM on their AMD builds?
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-...
They did support ECC on some i3 simply because they did not bother to double the sku, however IIRC you need the server / WS S chipset to enable it. At which point just put an entry level Xeon on that.
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.
With DDR5 you can have (a form of) ECC on all current 12th-generation Core CPUs. That is, if you were able to find DDR5 DIMMs on the market, which you currently cannot.
Not really: internal ECC in DDR5 is an implementation detail that is neither exposed on the bus nor giving you the real reliability and monitoring capability that real ECC terminated in the memory controller did. It is only there because the error rate would be absolutely horrific without, so you need internal ECC to get to basically the same point you were without ECC on DDR4.
I expect in-chip ECC should still be a significant improvement for RAM reliability (any ECC is going to be better than none, even if your memory array is significantly worse; I've had my share of RAM with weak bits that would absolutely be fixed with that), but it's not going to help with bus errors and isn't nearly as transparent to system software as end to end ECC is.
In theory some weak ECC on top of particularly unreliable storage can still be less reliable than way more reliable storage not employing any ECC, but I also suspect this won't be the case here. However, if the target reliability is only say 2 or 3 times what you had DDR4 without ECC, it is still completely unsuitable for serious applications. And really we should find another name for the internal ECC of DDR5, because the services it provides is completely different from real ECC.
In the industry we already have terms of art that are better than just “ECC”. Normally we speak of EDAC, error detection and correction. We refer to them by their capabilities, such as SECDED, ChipKill, or whatever.
As far as I can tell, Intel only offered ECC on a small handful of i3 parts that mainly seemed to be marketed to NAS manufacturers, likely because they were otherwise giving up that market entirely to competitors like AMD. They really don't seem to be interested in offering it as an option on consumer desktops.
"pretending we can have 512 billion bits of perfect memory sitting around that will never go wrong, because Intel fuse it off on desktop chips"
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.
My main worry with this sort of thing, is that if we start mandating legal liability, and security becomes a compliance line-item, then companies are going to start locking down everything they ship so they have a legal defense in court. The argument's going to be, "if we are liable for shipping insecure desktops then you shouldn't be allowed to install Linux onto them and then sue us when you get hacked".
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.
Since the Mac Pro has ECC Ram, I would expect a future Apple Silicon Mac Pro to offer it as well with its desktop M1 chip, with the functionality trickling down the line in years to come.
The DDR5 memory bus used by Intel's latest consumer processors does not have ECC enabled. The memory dies themselves have some internal ECC that is not exposed to the host system and is not related to the fact that they use a DDR5 interface; all state of the art DRAM now needs on-die ECC due to the high density.
So what it has on die ECC which allows to recover from radiation induced bitflips and stuff. Maybe to compensate for density the error correction is a bit more busy and can compensate less errors per minute but 0.5 ECC instead of full ECC on DDR4 (no random errors due to density) is still an improvement for most people in terms of immunity to unlucky cosmic rays.
Intel's lower end workstation chips are the same silicon, and thus the same manufacturing cost, as their desktop chips. They just artificially disable features like ECC for product segmentation. It is unconscionable that something as essential as ECC is crippled out of the consumer line-up.
ECC costs $0 to support in motherboards (8 extra traces per DIMM slot; traces are free). Memory is where the consumer gets to choose whether to spend extra on ECC or not. There is absolutely no reason why consumers should be forced to pay extra for a CPU to get ECC when they are literally getting the same piece of silicon.
It's odd how indifferent you are being about the energy costs of ECC. Memory now dominates the energy story of many systems. Filling an x86 cache line from DDR4 costs 1000x as much energy as a double-precision multiplication operation. ECC memory costs 12.5% more energy. That's a big, big difference.
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.
haha it's staggering how big the presence of NVIDIA is in the deep learning community, yet after all these years it's still a painful process to get all the drivers up and running in the correct way. Their documentation surroundg CUDA and CUDNN are often out of date and/ or incomplete. Staggering
Ok. On my end the first one I had that could do fast compute was a GTX 280, then a 590, then a 1080ti which I still have.
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.
They didn't get flipped off for having bad drivers. They got flipped off for having closed source off-tree drivers.
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.
Not the parent that you replied to, but I use full PCI passthrough for my Nvidia (RTX 3060) and it works just fine. I had no idea Nvidia had done this before or else I would've seriously reconsidered my choices for this build... Nevertheless it seems to work just fine.
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.
So it sounds like TB3 + USB4 would be a good docking station, and TB4 just makes it a bit better. So I shouldn't be too worried if I upgrade my laptop and it only has TB3.
if you are getting a framework to run a hackintosh why would you not get a macbook air? prolly cheaper in the long run and the M1 is a pretty great chip.
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.
Lets compare it to all the other options, shall we? Perfect is the enemy of good, and your uncompromising way of doing things (including not loading microcode 'because it is closed source') is, to put it simple: harmful. And unusual, as well (its not a dealbreaker for many people). The laptop is modular and repairable, just like a Fairphone is modular and repairable. Its a great step forward and, while not perfect and possibly a reason to not buy it, a minor detail for most people. If we should follow FSF's principles we would not be able to load microcode to fix Spectre 'because it is proprietary' like Trisquel apparently does. Meanwhile, Librem 5 delivers awful performance, and Pinephone offer 30 days warranty. Both have killswitches though: great feature. Again, perfect is the enemy of good. Because if killswitches are a requirement for you, then these are about your two options. If a modular laptop is a requirement for you, you are bound to what? Old Thinkpads?
...I'm more curious why firmware is even closed source. Seems to me, just releasing the assembler, documentation and a datasheet should be basic courtesy.
Then again everything I think that way about is apparently a mortal sin in the business world.
So, the thing is that, in proprietary software development, a lot of stuff is licensed and copied around, because the engineers need to get their jobs done on time. Legal makes sure that everyone actually is working with properly-licensed code (usually), but the definition of "properly-licensed" is going to be in the very narrow definition of "what do we need to license in order to ship the product".
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.
I hear hardware vendors are scared shitless of running awful of other hardware vendor's patents. If they released their firmware, this would give other folks ammunitions to attack them in court.
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.
Unfortunately, from my understanding, hardware innovation seems to be on a trajectory whereby it is exactly going toward the case that most functionality is "soft" and thereby fundamental changes can be wrought through microcode. Just look at Nvidia's use of FALCON's. Hardware manufacturers seemingly WANT to be able to use the same piece of hardware for different jobs, and having blobs tooled to reconfigure it is the way to go.
My biggest problem is that figuring this state of affairs out is like pulling teeth.
That’s the thing about microcoded machines: they’re fundamentally flexible. Even so, to be honest I don’t care too much about that. What I really want is a reliable, stable enough interface to the hardware.
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.
The FSF endorse ThinkPads with two or three chips running secret firmware blobs with full access to system memory via the LPC bus. They also endorse Bluetooth dongles running hundreds of kilobytes of proprietary firmware blob (which doesn't count for them because it's in ROM, not /lib/firmware).
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).
As my link already says, the FSF can and should be improved. However, I think there is a point in separating "hardware" from "software", where the former is not to be updated. If it can be updated by anyone, in any way, it's not hardware.
If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse engineer it, audit it, know they are running the exact version they expect, and potentially replace it with a free one.
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).
> 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.
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.
> If it can be updated by the user, even if the source code is not available, it is freer than if it cannot.
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.
> So we both say the same thing with different words. I agree, which is why there is a call to FSF for change.
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.
> I thought you were saying that hardware is whatever "cannot be updated".
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.
..and still, a Fairphone is more free than almost every smartphone out there. And still, a Framework is more free than almost every laptop out there. Because they are easily repairable because of their modularity. Something, yes, Thinkpads used to be too. But you're bound to old, refurbished ones (X230/T430 apparently) [1]. You don't care about that, you only care about one thing, and the rest is seemingly rationalized as irrelevant. Again, perfect is the enemy of good, akin to release early, release often.
> Fairphone is more free than almost every smartphone out there
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].
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 point is that the proprietary software has no access to the RAM or CPU and plays absolutely no role whatsoever in the device usage. I personally agree that it can be called "hardware" and don't care that it has another CPU.
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 point is that the proprietary software has no access to the RAM or CPU and plays absolutely no role whatsoever in the device usage.
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.
You are of course right that technically it has the 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.
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....
> I was under impression that it was the whole point of the exercise. It would be interesting to know otherwise.
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:
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:
The normal way this is done is the DDR training blob is just embedded into the bootloader like any other data, and the bootloader loads it into the PMU. Same exact end result, minus involving a Cortex-M4 core for no reason and minus sticking the blob in external flash for no reason. Here, this is how U-Boot does it on every other platform:
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):
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.
If it's a random community member then this is just further evidence that the way Librem presented things and what they did confused people into thinking it actually had a practical purpose, when it was purely a way to rules-lawyer their way into getting RYF.
Hi, I'm the "random community member" who wrote that FAQ answer. Thanks for investigating how this works. Where is the file cpu_rec.py located? I can't find it.
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:
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.
I wanted to add that I noticed this kind of all or nothing (or perfionist, or black and white thinking) all the time in the free software community, the vegan community, as well as the Fairphone community (who have made 4 iterations of a fair smartphone (fair being for environment and workers), as well as 3 iterations on a repairable, modular smartphone). They innovated long term support on smartphones for 3 iterations, and the competition is slowly but surely getting better there as well.
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.
> 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.
> 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.
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."
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.
>Apple decided to not block the use of custom kernels with the M1.
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.
The RYF certification program is based on Richard Stallman's outdated idea that hardware shouldn't be changed and software is anything that can be changed or updated after the device is produced. Anyone who looks at how x86 processors use microcode updates and the security threats with Meltdown and Spectre knows that a modern x86 PC needs to get microcode updates. Even worse is the fact that building a device to comply with RYF actually makes it more difficult to work on freeing the blobs. In the case of the Librem 5, you have to write to the SPI NOR Flash chip to replace the 4 blob files, rather than simply changing the files stored on in the /lib/firmware directory.
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)
> 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...
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.
>As I see it, we got lucky with the x86 architecture
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.
All RAM should be ECC. This intel ECC paywall is terrible. I have no actual need for ECC. My business is in cloud and personal doesn't really benefit too much from it.
> I always disliked Intel's strategy for market segmentation by disabling specific instructions,
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.
It's not "unofficial" support, it's just the motherboards/OEMs don't bother to implement it or implement it in an opaque way. All the motherboards have to do to support this properly is have the extra RAM traces and an easy setup menu info line that tells you whether ECC is on or not. The CPU supports it fine.
If you run Linux, you can use dmidecode and the EDAC driver to confirm if you have ECC enabled.
The Core 2 Quad Q8200 was what did it for me. I had intended to build a system to play with virtual machines, only to find after I built it up that the Q8200 didn't have VT-x - something that was NOT noted in the store display.
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.
to be fair, that's unavoidable with AVX-512, you can't underestimate how much power it draws compared to non-vectorised instructions.
That's why Prime95 is such an effective stress test and draws 150% of the power that Cinebench R20 does for example.
Didn't AMD disable cores on chips that were enabled and the exact same chips branded higher end? [0]
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.
Fair enough. I just bought a laptop with an Intel Core i7-1165G7.
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.
Between shenanigans like this and Spectre/Meltdown mitigations giving me a ~20% performance hit [1], I avoid Intel like the plague if I have the choice.
Pretty crap reasoning then. Intel never ever marketed these as having AVX-512 and unless you are running a Xeon from 2012 like the paper you've linked a modern CPU (note, any desktop class CPU) will only be vulnerable to some bits of Spectre and not meltdow
I did not expect the “I don’t have anything important enough” excuse on HN.
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.
Once power and heat in a chip go high enough, Electromigration causes reliability issues.
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.
This sort of thing is always a bad look for Intel, die costs are relatively fixed and "upselling" some of the transistors on the die for increased margins will always fail against a competitor who is willing to enable all the things (and AMD certainly seems to be in that camp). What it means is that AMD has an "easy" market strategy for continuing to beat Intel, just out feature them at a lower margin, turn Intel's fab capacity into an anchor rather than an asset.
The AVX-512 rollout has been a complete disaster. Look at how quickly AVX-2 became widespread and targetable. My all metrics, AVX-512 adoption has been abysmal and most of the blame lies squarely on Intel's shoulders. And even now that platforms are beginning to support it, developers just aren't interested because AVX-2 + optimizations got them most of the way there. Then there's the heavy performance hit that regular code intermixed with AVX-512 incurs.
That performance hit doesn't necessarily exist on a given workload, because the hysteria over downclocking was mainly with the very early desktop implementations of AVX-512. You'd have to measure it and see nowadays (and consider that the downclocking may be simply due to yourself actually using all the execution units at once)
Whether the hit is there or not is besides the point so long as it's perceived to be there by a not insignificant portion of the developers that might otherwise chase after an AVX-512 implementation.
(Citation needed for my initial claim that the perception of the performance hit exists within that population.)
You can only upgrade microcode on any given boot, not downgrade it. Therefore, if the BIOS has already upgraded your microcode for you on boot, you can't undo that from the OS.
I misread that there, so disregard the first reply.
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.
Common misconception about Intel microcode ROM is it's some sort of Flash memory, it's not. Update vaporizes each reset and the same "update" is loaded on each bootup.
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.
The BIOS itself comes with microcode. You upgrade your BIOS for whatever reason and it comes with new microcode applied on boot, which you can't disable. Sure, if you don't upgrade your BIOS you can keep using the old microcode. But you might have to to fix bugs or improve performance.
Do both E and P cores handle avx instructions or are some instructions specific to p-cores? In that case, how does a processor with heterogeneous cores deal with processes (or, how does the OS/driver do it in automatic mode when affinity isn’t guided)?
The elephant in the room is the classic CPU architecture mistake where you use two different instruction sets on your performance and efficiency cores. There is no way to prevent code with AVX-512 instructions from being executed on an unsupported core. This exact same problem that plagued early ARM big.LITTLE designs that used ARMv8.2 on the performance core but ARM8.0 on the efficiency core, forcing all code to use the more restrictive instruction set and cripple the performance benefits of the “big” cores.
Nope! You have to disable the efficiency cores to enable AVX-512. Between that and the relative scarcity of AVX-512 code, this isn’t really a big loss. It wasn’t like it was a free feature.
The E and P cores support the same instruction sets (apart from this thing where you could run AVX-512 on the P cores if you disabled the E cores, which is going away).
Microcode updates are applied at runtime, every time you boot them. At least on the CPU side. The motherboard might apply them before the OS loads though, so who knows what happens there
I think for the subset of people that care about having AVX512 on their 12900K, and bother to disable the E-cores to achieve it, they will be using enthusiast motherboards that don't block bios upgrades in this way.
Microcode downgrades are blocked by the CPU itself; the BIOS doesn't get a say. You could downgrade the whole BIOS to stop the upgrade being applied on boot (maybe, some motherboards may try to block this too), but then you need to choose between uncrippled microcode and BIOS bugfixes and improvements.
I wouldnt call it hacking. If you can find or backup the bios image for your motherboard, you can replace the microcode in it and reflash. Bios images are modular and the microcode is a replacable component.
Hacking BIOS images isn't always that easy. Often they are signed (EFI Capsules) and the standard update utility in the BIOS menu will reject modified versions. I had to use a convoluted flashing process to make a trivial patch to a BIOS a few years back for this reason.
That usually works, yes (modulo Boot Guard and electrical issues), but we're getting into less accessible methods, aren't we :)
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.
Unsurprising given their history regarding such moves.Kind of sad, some people in the linux community knew about the fact that alder lake is avx-512 capable.Also even if they did not advertise the product with this feature, can't they still be sued for worsening a product post-purchase?
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.
Intel has always been doing artificial market segmentation. I would only be surprised if they somehow release a cpu generation with the same features across all models...
"I hope AVX512 dies a painful death, and that Intel starts fixing real problems instead of trying to create magic instructions to then create benchmarks that they can look good on…
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
Intel never sold Alder Lake with AVX512 support but only underlying P-core technically supported. They failed to completely disable it. I believe they don't validated AVX512 functionality because anyway they don't support. It's not fair to blame disabling.
The article as some bits of the chip marked off (with big red X's). They look reasonably sized to be the AVX-512 parts, in the sense that they are quite large but not the majority of the chip or anything.
Excuse my ignorance but what is AVX-512 even supposed to improve? I’ve been hearing about this instruction set since around 2015 and I have yet to hear or see any significant use case for these instructions.
Some crypto miners use it instead of dedicated Asics, its intense cpu processing but at the expense of everything else running through the cpu, its a cludge but Intel have said they are looking at dedicated crypto mining cpu's to maybe get in on the inflated GPU price tags people currently see. I read somewhere Nvidia have even added some features which prevents their GPU's from being used for mining.
AVX-512 is possibly a go-to place for stealth crypto mining for some hackers in server farms.
No, the AVX-512 instructions weren’t free. You had to disable all of the E cores. It only made sense if you could afford to give up the extra cores to accelerate a few instructions in a smaller number of threads.
It wasn’t a net win for the average person. I doubt many people would ever do this.
E cores are only present on the high-end Alder Lake SKUs. If you have a mid-range chip with only P cores like the i5-12400, enabling AVX-512 really is free.
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.
It was never advertised, and Intel very specifically said AVX-512 instructions will not be available. Some motherboard manufacturers made them available anyway, now Intel is fixing that.
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.
Not sure how others do it, but I don't only buy products based on advertisements, but rather by the actual properties the product has.
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.
If AVX-512 was not in scope yet left turned on, parts may operate outside design limits, there's system-level validation that may not have been run, and specs that are at risk. Think about the scale of all PC OEMs that use these CPUs, rather than a specific product.
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.
There was no specification about this feature until immediately prior to launch.
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.
Sure, but that's a customer expectation vs legal obligation.
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.
The difference is dual screens don't work on the M1 MBA because it physically only has two display controllers in the silicon, one of them wired to the internal panel, and the other muxed to the two TB ports. The M1 Pro has two external display controllers, and the M1 Max four. I can show you where they are on the die shots, and that it's not artificial crippling.
But what Intel is doing here is disabling existing silicon that exists and works.
Sure, but as a customer that's irrelevant, right? You had a MacBook Air, used it with two displays, then you buy a new MacBook Air and bam, it doesn't work with two displays. The technical nitty gritty is not really relevant - at least the comment I was replying to sounded this way. That what the customer expects is more important than what is on the spec sheet? The fact that previous Intel CPU supported AVX-512, and the new one doesn't - so whether this fact is or isn't mentioned in the spec sheet is not important, because what the customer expects should be ultimately what decides what is "ok".
Yes, but once it has shipped and people may have come to depend on it it will break stuff, not fix stuff.
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.
>>Yes, but once it has shipped and people may have come to depend on it it will break stuff, not fix stuff.
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.
> Yes, but once it has shipped and people may have come to depend on it it will break stuff, not fix stuff.
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.
To add to this - even if the motherboard manufacturer allows this despite Intel's advice, in their stock configuration none of those CPUs allow AVX-512 instructions out of the box. You need to knowingly and conciously go into the BIOS and disable all efficiency cores first, to make this option even appear. So "as sold" the product doesn't support AVX-512 instructions and the advertising is absolutely correct. Just like you can overclock the CPU but it doesn't come overclocked out of the box(and Intel assumes no liability if you do overclock it).
Intel very specifically said that AVX-512 instructions will not be available only a few weeks before the Alder Lake launch.
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.
>>Whether AVX-512 can be enabled by disabling the Gracemont cores was not said
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.
Good example. It’s like buying a car and finding out it has a nice radio that was not advertised. After a few months the car dealership sends someone to break into the car and rip it off. Fair enough since it wasn’t advertised, right?
Well, breaking into your car is still illegal, so no, not fair enough.
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.
This has nothing to do with advertisement. You should not be able to retroactively make products that you've already sold to people be less useful, whether or not the feature you're clawing back was advertised.
I disagree completely. The product as sold wasn't compliant with its own technical spec sheet - now after the update it is. The feature isn't supported by that CPU and it should have never been exposed to the consumer. If you discovered that the CPU has 8 cores despite being sold as a 6 core, then removing 2 cores with a BIOS update wouldn't be "making the product less useful" either. It just makes the product exactly as specified in its technical documentation - and that is how it should be.
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.
> If you discovered that the CPU has 8 cores despite being sold as a 6 core, then removing 2 cores with a BIOS update wouldn't be "making the product less useful" either.
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.
It's not even undocumented, but explicitly a documented as a feature those CPUs don't have. Originally it was supposed to be fused off physically, I wonder why it wasn't.
Who did this? Phoronix got AVX-512 working, but was very clear that this was unexpected and had a good chance of going away before release. If anything, this is a better test for your reviewers -- if a reviewer has published benchmarks using these unsupported features without mentioning it, you should keep that in mind when listening to their reviews in the future.
It could be that decision to not support AVX512 was made very late in product development and thus early batches didn't have chicken bit disabled or/and fused it off.
There might be gazillions of reason why this was done.
I'm not sure if benchmarks that are out have the AVX-512 enabled or not.
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.
You had to explicitly turn it on through hacks in the BIOS some motherboard makers added. If people enable a feature that's explicitly not supported on their benchmark rigs without disclosing it, that's not the vendors fault.
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.