Wednesday, October 16th 2024
What the Intel-AMD x86 Ecosystem Advisory Group is, and What it's Not
AVX-512 was proposed by Intel more than a decade ago—in 2013 to be precise. A decade later, the implementation of this instruction set on CPU cores remains wildly spotty—Intel implemented it first on an HPC accelerator, then its Xeon server processors, then its client processors, before realizing that hardware hasn't caught up with the technology to execute AVX-512 instructions in an energy-efficient manner, before deprecating it on the client. AMD implemented it just a couple of years ago with Zen 4 with a dual-pumped 256-bit FPU on 5 nm, before finally implementing a true 512-bit FPU on 4 nm. AVX-512 is a microcosm of what's wrong with the x86 ecosystem.
There are only two x86 CPU core vendors, the IP owner Intel, and its only surviving licensee capable of contemporary CPU cores, AMD. Any new additions to the ISA introduced by either of the two have to go through the grind of their duopolistic competition before software vendors could assume that there's a uniform install base to implement something new. x86 is a net-loser of this, and Arm is a net-winner. Arm Holdings makes no hardware of its own, except continuously developing the Arm machine architecture, and a first-party set of reference-design CPU cores that any licensee can implement. Arm's great march began with tiny embedded devices, before its explosion into client computing with smartphone SoCs. There are now Arm-based server processors, and the architecture is making inroads to the last market that x86 holds sway over—the PC. Apple's M-series processors compete with all segments of PC processors—right from the 7 W class, to the HEDT/workstation class. Qualcomm entered this space with its Snapdragon Elite family, and now Dell believes NVIDIA will take a swing at client processors in 2025. Then there's RISC-V. Intel finally did something it should have done two decades ago—set up a multi-brand Ecosystem Advisory Group. Here's what it is, and more importantly, what it's not.
On Tuesday, 15th October, Intel and AMD jointly announced the x86 Ecosystem Advisory Group. The two companies are equals in this group as x86 processor vendors. There are a few founding members that are big names in the tech industry, and a couple of eminent industry leaders. These include Dell, Broadcom, Google Cloud, HP, HPE, Lenovo, Meta, Microsoft, Oracle, and Red Hat. The luminaries include Linus Torvalds, the creator of Linux, and Tim Sweeney of Epic Games. You can categorize the above list of founding members and luminaries into client-relevant and enterprise-relevant. Tim Sweeney is one of the biggest names in the gaming industry, with Unreal Engine dominating all gaming platforms. Linux is predominantly an enterprise OS—no, Android is not a Linux distribution, it's a highly differentiated OS with its own APIs, which happens to use the Linux kernel.
What the x86 Ecosystem Advisory Group is
It is a special interest group consisting of Intel, AMD (hardware vendors), founding members, and industry luminaries, making sure x86 is consistent as a machine architecture, and there's two-way communication among the hardware vendors and the members of the group, to shape the future of x86. Put simply, it aims to create and implement standards in architectural interfaces, and most importantly, the ISA—or instruction sets.
We began our write-up by going into the test case of AVX-512. The x86 Ecosystem Advisory Group is being set up to prevent exactly that from happening, where 11 years into its conception, AVX-512 has a wildly inconsistent implementation within Intel and AMD, and their product stacks, and so ISVs would rather not implement it. x86 suffers competitiveness in performance against other machine architectures and their instruction-sets.
The Advisory Group's main aim is to ensure the latest ISA and hardware interfaces are jointly developed, implemented, and there is compatibility across the ecosystem, so future technology is more predictable, and the ISVs can respond better to them.
What the Ecosystem Advisory Group is Not
Intel "Arrow Lake" and AMD "Granite Ridge" are nothing alike on the hardware level—they are two completely different pieces of silicon, with a different chip design, and their CPU cores are nothing alike at a hardware level. The only things common between them is the x86 ISA, and a few industry-standard platform interfaces such as the memory and PCIe. And yet, despite such vast amounts of differentiation in hardware design, Intel and AMD processors end up with performance deltas within 5% in a given price segment. This diversity of hardware design is not going to change.
The Ecosystem Advisory Group does not aim to standardize the x86 core, just the ISA. It is a means for the ISV ecosystem to constantly tell Intel and AMD what they expect, and for the two companies to deliver on them. "Here's our CPU core, it can handle the same instructions as our competitor's core, but with better performance and efficiency"—this would be the end-goal of the Ecosystem as far as the hardware vendors are concerned. For the ISV, it's the assurance that by year 2029, the next new instruction-set will be generally available from both Intel and AMD, and they could plan their software product development roadmap to align with that.
What's Next? Is this Enough?
Setting up of this Ecosystem Advisory Group could not have been possible without Intel, which is the IP owner for x86. AMD probably got on board because it sees the value in having such an ecosystem, and a more equitable sharing of technologies with Intel concerning instruction sets and architecture interfaces. But is this enough to go up against Arm and RISC-V? Arm has had a two-decade head-start in having an architecture review board, and the list of hardware vendors implementing Arm dwarfs x86 by a factor of 20. Even someone like MediaTek, which primarily focuses on smartphone SoCs, can develop a new server processor in under a year. x86 needs fresh blood in the hardware vendor space, but this can only happen if Intel and AMD are willing to give up some market share.
The x86 machine architecture is in serious need of housekeeping, and x86S is its future. A 64-bit only version of x86, which sheds 32-bit application compatibility, the standardization of x86S could be sped up with the setting up of the Ecosystem Advisory Group. x86S sheds the 16-bit real-mode, 32-bit protected mode, and v86 (virtual 8086) mode, gets rid of legacy task-switching mechanism, vastly simplifies interrupt handling, enhances security by dropping ring-1 and ring-2 privilege levels (leaving just ring-0 and ring-3 user mode), and improved memory management by eliminating non-long mode paging structures. These changes vastly simplify x86, improve security, and makes x86 more future-ready. The transition to x86S will prove crucial for the future of x86, and something like the x86 Ecosystem Advisory Group couldn't have come at a better time. There are other allied forward-facing developments, such as UCIe, which makes designing disaggregated chips easier, OpenSIL on-chip hardware initialization (a microcode standardization).
In conclusion, the Intel-AMD x86 Ecosystem Advisory Group is nice to have, there is finally something to mitigate the harmful effects of an intensely competitive duopoly and ensure x86 can face Arm better into the next couple of decades, by smoothening out the much-needed transition to x86S, OpenSIL, and other future technologies. This does not hamper innovation, and there remains sufficient incentive for Intel and AMD to keep pushing for faster and more efficient microarchitectures.
There are only two x86 CPU core vendors, the IP owner Intel, and its only surviving licensee capable of contemporary CPU cores, AMD. Any new additions to the ISA introduced by either of the two have to go through the grind of their duopolistic competition before software vendors could assume that there's a uniform install base to implement something new. x86 is a net-loser of this, and Arm is a net-winner. Arm Holdings makes no hardware of its own, except continuously developing the Arm machine architecture, and a first-party set of reference-design CPU cores that any licensee can implement. Arm's great march began with tiny embedded devices, before its explosion into client computing with smartphone SoCs. There are now Arm-based server processors, and the architecture is making inroads to the last market that x86 holds sway over—the PC. Apple's M-series processors compete with all segments of PC processors—right from the 7 W class, to the HEDT/workstation class. Qualcomm entered this space with its Snapdragon Elite family, and now Dell believes NVIDIA will take a swing at client processors in 2025. Then there's RISC-V. Intel finally did something it should have done two decades ago—set up a multi-brand Ecosystem Advisory Group. Here's what it is, and more importantly, what it's not.
What the x86 Ecosystem Advisory Group is
It is a special interest group consisting of Intel, AMD (hardware vendors), founding members, and industry luminaries, making sure x86 is consistent as a machine architecture, and there's two-way communication among the hardware vendors and the members of the group, to shape the future of x86. Put simply, it aims to create and implement standards in architectural interfaces, and most importantly, the ISA—or instruction sets.
We began our write-up by going into the test case of AVX-512. The x86 Ecosystem Advisory Group is being set up to prevent exactly that from happening, where 11 years into its conception, AVX-512 has a wildly inconsistent implementation within Intel and AMD, and their product stacks, and so ISVs would rather not implement it. x86 suffers competitiveness in performance against other machine architectures and their instruction-sets.
The Advisory Group's main aim is to ensure the latest ISA and hardware interfaces are jointly developed, implemented, and there is compatibility across the ecosystem, so future technology is more predictable, and the ISVs can respond better to them.
What the Ecosystem Advisory Group is Not
Intel "Arrow Lake" and AMD "Granite Ridge" are nothing alike on the hardware level—they are two completely different pieces of silicon, with a different chip design, and their CPU cores are nothing alike at a hardware level. The only things common between them is the x86 ISA, and a few industry-standard platform interfaces such as the memory and PCIe. And yet, despite such vast amounts of differentiation in hardware design, Intel and AMD processors end up with performance deltas within 5% in a given price segment. This diversity of hardware design is not going to change.
The Ecosystem Advisory Group does not aim to standardize the x86 core, just the ISA. It is a means for the ISV ecosystem to constantly tell Intel and AMD what they expect, and for the two companies to deliver on them. "Here's our CPU core, it can handle the same instructions as our competitor's core, but with better performance and efficiency"—this would be the end-goal of the Ecosystem as far as the hardware vendors are concerned. For the ISV, it's the assurance that by year 2029, the next new instruction-set will be generally available from both Intel and AMD, and they could plan their software product development roadmap to align with that.
What's Next? Is this Enough?
Setting up of this Ecosystem Advisory Group could not have been possible without Intel, which is the IP owner for x86. AMD probably got on board because it sees the value in having such an ecosystem, and a more equitable sharing of technologies with Intel concerning instruction sets and architecture interfaces. But is this enough to go up against Arm and RISC-V? Arm has had a two-decade head-start in having an architecture review board, and the list of hardware vendors implementing Arm dwarfs x86 by a factor of 20. Even someone like MediaTek, which primarily focuses on smartphone SoCs, can develop a new server processor in under a year. x86 needs fresh blood in the hardware vendor space, but this can only happen if Intel and AMD are willing to give up some market share.
The x86 machine architecture is in serious need of housekeeping, and x86S is its future. A 64-bit only version of x86, which sheds 32-bit application compatibility, the standardization of x86S could be sped up with the setting up of the Ecosystem Advisory Group. x86S sheds the 16-bit real-mode, 32-bit protected mode, and v86 (virtual 8086) mode, gets rid of legacy task-switching mechanism, vastly simplifies interrupt handling, enhances security by dropping ring-1 and ring-2 privilege levels (leaving just ring-0 and ring-3 user mode), and improved memory management by eliminating non-long mode paging structures. These changes vastly simplify x86, improve security, and makes x86 more future-ready. The transition to x86S will prove crucial for the future of x86, and something like the x86 Ecosystem Advisory Group couldn't have come at a better time. There are other allied forward-facing developments, such as UCIe, which makes designing disaggregated chips easier, OpenSIL on-chip hardware initialization (a microcode standardization).
In conclusion, the Intel-AMD x86 Ecosystem Advisory Group is nice to have, there is finally something to mitigate the harmful effects of an intensely competitive duopoly and ensure x86 can face Arm better into the next couple of decades, by smoothening out the much-needed transition to x86S, OpenSIL, and other future technologies. This does not hamper innovation, and there remains sufficient incentive for Intel and AMD to keep pushing for faster and more efficient microarchitectures.
18 Comments on What the Intel-AMD x86 Ecosystem Advisory Group is, and What it's Not
(source)
As for AVX-512 it should be mentioned that even on ARM advanced instruction support in the AArch64 ISA is split into ARMv8.x-A and ARMv9.x-A. Some vendors only implement the former without Scalable Vector Extension (SVE) or Scalable Matrix Extension (SME) which are roughly equivalent to the AVX family and Intel AMX.
The plans for future Intel implementations of AVX-512 with AVX10.x are still problematic. AVX10.x-256 is supposed to target all processors with 256-bit width and AVX10.x-512 would be for servers. They are not binary compatible as in you can't run AVX10.x-512 on a 256-bit width CPU - it has to be recompiled for AVX10.x-256 or use some kind of dynamic targeting (just like AVX2/AVX-512 now). It still brings desirable features to 256-bit width SKUs, and guarantees backward compatibility in versions, so it is a step forward.
AMD isn't the only whom produced it, bot not everyone had/purchased the rights, see Soviet Union:
KR580VM80A
If x86 is about a high number of hardware implemented instructions (vs ARM/RISC), shouldn't engineers extend and dictate how code and compilers should be written more... Instead of predicting what comes next, where's the hardware array/list functions... one cycle instructions... the hard work.
The 80186 was (roughly) the microcontroller version of the 80286. Interestingly, I can find pics of them marked with Ⓜ AMD © INTEL, or © AMD, or Ⓜ © INTEL (still made by AMD), or Ⓜ © AMD © INTEL. AMD also used both type numbers, 80186 and Am186. This probably hints at their magnificent army of lawyers, engineers, reverse engineers, and reverse lawyers.
The M in cirlce means ... this?AMD's 256-bit implementation of AVX-512 is binary compatible with the "true" 512-bit implementation, only the peformance is lower, right?
Maybe Intel will create something similar that will allow 256-bit wide CPUs to run AVX10.x-512 binaries, but at the moment from the specifications it doesn't look like it.
Funnily enough Skymont, the latest E-core microarchitecture already implements 256-bit AVX2 on two 128-bit units, and the core itself has 4x 128-bit FP units:
(source)
Incidentally, AMD made other interesting things, with chip art too.AMD's double-pumping arrangements had been remarkably efficient, and faster than just keep using AVX2/FMA3. I think y-cruncher's author did a deep dive of this when Zen 4 came out.
Arm is not exactly foreign to that sort of thing.
(source)
In any case since AVX-512 allows more dense packing of math operations than AVX2 (since it's a wider SIMD) in Zen 4's case it allowed the frontend to be less loaded. In turn the execution units were not as starved and performed more work in the same time. Since the decoding frontend was less loaded it consumed less power allowing the core to clock higher. A detailed analysis of it can be read here.