Intel completely disables AVX-512 on Alder Lake after all

Intel is now set to disable “AVX-512” completely on all Alder Lake CPUs with an upcoming microcode update in new BIOS releases. Mainboard manufacturers were able to make the supposedly disabled instruction set available at launch, which resulted in a significant performance increase for the P-cores of the new CPUs. Now Intel is tightening the noose completely after all and, according to our sources, has instructed motherboard manufacturers to completely disable the “unsupported” feature.

Just in time for the launch of the new smaller CPU SKUs and motherboard chipsets at CES next week, all existing Z690 motherboards are supposed to completely disable the AVX-512 instruction set via a BIOS update. So far, we can only speculate about the motives. However, it would be logical that Intel would want to artificially create a sales argument for upcoming workstation and server products. This is because applications in the enterprise sector in particular often benefit the most from the acceleration provided by the AVX-512 instruction set. Actually completely capable “consumer” hardware should, if Intel has its way, no longer be a valid option here. To protect our sources, we do not wish to name them.

But that’s not all, because the remaining AVX2 instruction set is already limited by Intel to a multiplier of x51. While the set clock rate of 5.2 GHz, for example, is continuously available in applications without AVX2, such as Cinebench, and benchmark high scores can be achieved, the picture looks different in applications like LinpackXtreme. Even if you set the CPU clock to static in the BIOS, remove all performance limits and ensure sufficient cooling, the CPU throttles itself down to 5.1 GHz when executing AVX2 instructions. It also doesn’t matter how warm the CPU runs, how much power it consumes, or what the application is called. In HWInfo the intervention of the clock limit is recognizable by “IA: Max Turbo Limit – Yes”.


Why Intel limits the clock speed for AVX2 is not confirmed yet. One possible reason could be fear of degradation due to electron migration at too high current levels – a phenomenon where the CPU slowly damages itself over time. To be fair, due to the generally very high heat density of the new CPUs, only very few users probably use an appropriate cooling system to ever be able to run such high clock rates with AVX2. But for example who uses a custom water cooling loop or even delids the CPU in search of the absolute performance maximum, will sooner or later come up against this artificial limit of these otherwise “unlocked” CPUs. By the way, this limit was already present in Rocket Lake CPUs and was probably just not really covered because the product generation was generally much less interesting.

Fortunately, there are already workarounds for both of these AVX hurdles, the throttling of AVX2 and the removal of AVX-512. For example, Asus has implemented a patch in their BIOS versions for “Maximus” series motherboards that disables AVX2 throttling. The only important thing here is that the clock must already be set in the BIOS at boot time. A subsequent change via in-OS software will otherwise get caught in Intel’s catch net again.

To continue using AVX-512 requires slightly more exotic methods, but nothing impossible. Community members have already managed to inject an older microcode version into new BIOS releases, effectively providing a modified BIOS image with AVX-512 support. Of course, there is always a certain risk associated with such unofficial BIOS versions, since an error in the image could, for example, cause damage to the hardware. The use of such BIOS images is therefore always at your own risk! But at least this also shows that the deactivation of AVX-512 is reversible and thre is no downgrade-protection to the microcode version – at least at this point.

As the compatibility with DDR5 is still very much problematic and motherboard vendors are pushing fixes in new BIOS updates almost daily, many users now stand at a crossroads: Either install the new BIOS update for better DDR5 support and accept the removal of AVX-512, or not updating the BIOS, keep AVX-512 and stay limited in DDR5 compatibility, or install a BIOS from an unknown source that solves both problems, but might bring more in its self.

It remains the question to Intel: Why create all these artificial limitations? Is there really that much fear of the competition over at team blue, that they not only keep their aces up their sleeves, but even pull back already played cards? Of course, heavy market segmentation is nothing new for Intel, keywords “vROC’ or “only offering quad-core mainstream SKUs for the first 7 Intel Core generations”. In both cases the blue giant only moved once it was forced to by the competition. But to now retroactively neuter already sold CPUs in their functionality really does leave an exceptionally sour taste in customers mouths, even if AVX-512 was officially never supported on Alder Lake.  

In our tests we could already prove that AVX-512 on the Golden Cove P cores is indeed more efficient than AVX2 and even allows more computing power with less power consumption. The only prerequisite for AVX-512 is of course the deactivation of the Gracemont E cores, which simply physically lack the transistors for this instruction set. But we’ve also seen in our tests that the e-cores only provide performance gains in very few individual cases anyway, if not the outright opposite by slowing down the cache/ring and delaying memory accesses. Does the “E” then really still stand for “Efficiency” and not rather “Error” or “E-Waste”? Wouldn’t a CPU with only P-cores and AVX-512 be the far more economic and ecological approach?

And even if AVX-512 is taken away from us normal end users again and we have to put up with it in the end, one could at least expect foresighted and clear communication from Intel’s side in the future. Intel knew or should have known before the launch that Alder Lake CPUs can run AVX-512 and should have given clear instructions to the motherboard manufacturers in advance whether the feature could be enabled or not.

And also for AVX2 throttling, a footnote would be desirable in the specifications of “unlocked” K-SKUs. This would provide clarification in advance under which circumstances and why the CPU down clocks itself. Just another line for each Rocket/Alder Lake CPU on “Maximum AVX2 clock: 5.1 GHz” and “Protects against damage caused by excessive Vcore currents during AVX2 instructions” would be a start. Because even though strictly speaking you can still raise the effective clock above 5.1 GHz by increasing the BCLK from 100 MHz, this is really not an intuitive interpretation or simple usage of an Intel “K” CPU.

Join the pack! Join 8000+ others registered users, and get chat, make groups, post updates and make friends around the world!
Read More



  1. 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. 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.