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.
47 Comments on What the Intel-AMD x86 Ecosystem Advisory Group is, and What it's Not
At first, that front end was one of the reason why x86 was less efficient, but CPU got so large that the front end is a small portion of the whole core anyway.
Also, if you look at the latest arm instructions sets, i wonder if it can still be called RISC. They now too have a front end.
In the end, one of the main reason what x86 core are less efficients is most x86 arch aim the server market where they do not need low power efficiency. They didnt spend a lot of R&D into low power architecture because it was not useful. ARM on the other side was aiming for the low power market and all manufacturer aimed their R&D for low power devices.
Intel and AMD made small attempt at low power but they would probably have needed way too much money to get competitive and anyway, they aim at high marging server market and not the low margin mobile market.
It was a Complete Disaster. Period. The point of view is based on my software development experience using Intel KNL Server with a Xeon Phi CPU.
>>...A decade later, the implementation of this instruction set on CPU cores remains wildly spotty
This is because AVX-512 is Too Fragmented. Period. Again, the point of view is based on my software development experience using Intel KNL Server with a Xeon Phi CPU.
>>...Intel implemented it first on an HPC accelerator, then its Xeon server processors...
Intel KNL Servers with a Xeon Phi series CPUs.
>>...before realizing that hardware hasn't caught up with the technology to execute AVX-512 instructions in an energy-efficient manner...
Energy-efficient... Really? It was an Energy Hog! I also would like to add that it was Too Expensive compared to NVIDIA GPUs.
>>...AMD implemented it just a couple of years ago...
Absolute mistake because most software developers do Not care about AVX-512 ISA.
About this announcement, I would love the return of a shared/compatible CPU socket.
That would reduce the prices of future motherboards, I think.
FWIW and to my 200-level assembly language sensibility, base m68k was so much more elegant and easier to use than base x86. An alternate history with some spun-off Motorola subsidiary operating in Intel's niche and Intel operating in, say, Micron's niche in real world could have been fun to read about.
or AMD will just adopt RISC-V cores on extra chiplet :)
The iGPU, being used as a co-processor, is capable of being dozens of times faster than x86 cores.
And, of course, there should be a standard between Intel and AMD processors in order to the same software can run on the iGPUs of both companies.
If Nvidia starts to act strongly in the ARM processor market, it can easily and quickly implement the above, as it already has ready all the GPU hardware technology and the software support for it and also has an extremely good relationship with software developers.
This is actually what killed SLI/Crossfire. The dedicated link between GPU was not even fast enough to be able to give decent performance.
With DirectX 12, it's not impossible to do, but it would be a nightmare as the number of dedicated GPU pairing with a same architecture iGPU that could use the same driver and same compiled shaders is incredibly small.
Not counting that temporal effect are very common. This killed the last hope of Crossfire/SLI as you have to reuse the data of multiple previous frame.
I said that the iGPU should be used as a general purpose co-processor, for tasks where it can be used as a coprocessor, since for some tasks the iGPU can be tens of times faster than x86 cores and consuming a small fraction of the energy that x86 cores would consume to do the same task.
If Nvidia is going to enter the consumer processor market, it seems that it is exactly what it will do.
And this idea of using the iGPU as a general-purpose co-processor is not new. AMD engineers had this idea over 20 years ago. This was even one of the reasons AMD bought ATI.
Without mentioning names, companies X and Y have always helped each other in secret during each other's difficult times. Maybe this idea of using the iGPU as a co-processor was not implemented more than 10 years ago because both companies (X and Y) made an agreement, always in secret (of course), to one of both companies would not ruin the profits of the other.
Anyhow, your point is not really related to x86, that's has nothing to do with the ISA, that's more of a software thing. Some software already makes use of Quick Sync (which lives inside Intel's iGPU) for some tasks, as an example.
8086 was from Intel's naming scheme at the time. Its been a while and I am sure there is a guide somewhere in the Internet but from what I recall:
1st digit was about technology, I believe it started with PMOS, NMOS etc but the ones interesting to us are 4 and 8 which denote 4-bit and 8-bit chips (at least initially, since 8086 is 16-bit).
2nd digit was chip type. 0 processor, 1 RAM, 2 controller, 3 ROM etc.
Last 2 were generally sequence but sometimes pretty freeform. Not all numbers got to be a product and it was not always a sequence. "Sounds nice" was sometimes a deciding factor as well.
[SIZE=4]To add to [USER=169790]londiste[/USER]'s reply, the 8086 was directly preceeded by the 8085 (the 5 because it had a single 5V power supply) and before that the 8080 and 8008. All the later chips were source code compatible with the earlier ones with the appropriate assemblers.[/SIZE]
Intel's first DRAM chip was the 1103. ROMs were 23xx, EPROMs were 27xx, EEPROMS/flash were (and still are) 29xx, where xx was the capacity in kilobits.
And it continues to this day. The Raptor Lake desktop chip is 80715. The Z97 chipset was DH82Z97 but I'm not sure if newer chipset follow the same scheme.
Edit: I'm just leaving thishere. The story of the Intel 2114 static RAM, put together by some stupid AI and not to be fully trusted, but interesting nevertheless.