Hacker News Reader

Comment by zinekeller | Hacker News Reader

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.

View on HN

"cuts" are almost always fuses that are blown by ATEs during wafer manufacturing or post packaging tests. It is a bit flip.

There is no extra cost.

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.

1 - https://static.techspot.com/articles-info/1840/images/2019-0...

Then why not leave it as an option for people who want to experiment with the feature?

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.

One word: support.

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.

They don't support CPUs that were overclocked, yet advertise that feature, so support isn't the reason.

> yet advertise that feature

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.

> One word: support.

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.

You can still use the feature at your own risk - no one is forcing you to install the microcode update.

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.

Reply on news.ycombinator.com