Intel, AMD, team with tech titans for x86 ISA overhaul
(2024/10/15)
- Reference: 1729014063
- News link: https://www.theregister.co.uk/2024/10/15/intel_amd_x86_future/
- Source link:
The shape of the x86 instruction set architecture (ISA) is evolving. On Tuesday, Intel and AMD announced the formation of an ecosystem advisory group intended to drive greater consistency between the brands' x86 implementations.
Intel and AMD have been co-developing the x86-64 instruction for decades. But while end user workloads have enjoyed cross-compatibility between the two chipmakers' products, this has been far from universal.
"x86 is the de facto standard. It's a strong ecosystem, but it's one that really Intel and AMD have co-developed in a way, but an arm's length, and you know, that has caused some inefficiencies and some drift in portions of the ISA over time." AMD EVP of datacenter solutions Forrest Norrod said during a press briefing ahead of the announcement.
[1]
The introduction of advanced vector extensions (AVX) is the most obvious example of where compatibility across Intel and AMD platforms hasn't always been guaranteed.
[2]
[3]
For many years, those who wanted to take advantage of fat 512-bit vector registers have been limited to Intel platforms. In fact, AMD lacked support for AVX-512 until the [4]launch of Zen 4 in 2022, and even then it only supported it by double pumping a 256-bit data path. It wasn't until this year's Zen 5 [5]launch the House of Zen added support for a full 512-bit data path.
Going forward, Intel, AMD, and their industry partners aim to avoid this kind of inconsistency by converging around a more uniform implementation. To support this goal, the duo has solicited the help of Broadcom, Dell, Google, HPE, HP, Lenovo, Meta, Microsoft, Oracle, Red Hat, as well as individuals, including Linux kernel-dev Linus Torvalds and Epic's Tim Sweeney.
[6]
This advisory group will be tasked with reshaping the x86 ISA to improve cross-compatibility, simplify software development, and address changing demands around emerging technologies.
"We'll have, not only will we have the benefits of performance, flexibility and compatibility across hardware, we'll have it across software, operating systems and a variety of services," Intel EVP of datacenter and AI group Justin Hotard told us.
"I think this will actually enable greater choice in the fundamental products, but reduce the friction of being able to choose from those choices," echoed Norrod.
[7]
However, it'll be some time before we see the group's influence realized in products. Norrod emphasized that silicon development can take months if not years. As such it's "not something that's going to reflect into products, I don't believe, in the next year or so."
For end users, the benefits are numerous as in theory taking advantage of either Intel or AMD's products will require less specialization, something we're sure the hyperscalers will appreciate.
For the long-time rivals, however, the change could have major implications for the future development of the architecture. While the two chipmakers have caught up with each other on vector extensions, Intel still has its advanced matrix extensions (AMX) for CPU-based AI inference acceleration.
It remains to be seen whether these extensions will be phased out or if some version of them will eventually make their way into AMD's Epyc and Ryzen processors. We have no doubt that either team's SoC designers would relish the opportunity to reclaim all that die area currently consumed by the NPU.
"I don't think we want to commit to 'we're going to support this or not support this' in a time frame. But I think the intent is we want to support things consistently," Hotard said.
While Norrod and Hotard declined to comment on specific changes coming to x86, recent developments, particularly on Intel's side, give us some idea of the ISA's trajectory.
In June, Intel published an update to its proposed [8]x86S spec , a stripped down version of the ISA free of legacy bloat — most notably 32-bit and 16-bit execution modes. As we understand it, 32-bit code would still be able to run, albeit in a compatibility mode.
There's also the AVX10 spec that we [9]looked at last year, which made many of AVX512's more attractive functions. Under the new spec, AVX10 compatible chips will, for the most part, share a common feature set — including 32 registers, k-masks, and FP16 support — and minimally support 256 bit wide registers.
AVX10 is important for Intel which has transitioned to a dual-stack Xeon roadmap with P-and E-core CPUs, like Granite Rapids and Sierra Forest, the latter of which lacks support for AVX512.
[10]AMD pumps Epyc core count to 192, clocks up to 5 GHz with Turin debut
[11]Samsung's HBM3E has been a disaster, but there's a path back
[12]With Granite Rapids, Intel is back to trading blows with AMD
[13]SiFive expands from RISC-V cores for AI chips to designing its own full-fat accelerator
AMD's dense Zen C-cores don't suffer from this limitation, but can be switched to a double pumped 256-bit data path to achieve lower power AVX512 support. Whether Intel will push ahead with AVX10 or borrow AMD's implementation under the newly formed advisory group is another unknown, but given enough time, we can expect the two chipmakers to coalesce around a common implementation whether it be AVX, AMX or something else.
That's assuming, of course, that Intel and AMD can agree on how to address industry needs.
With that said, a more consistent ISA could help stave off the growing number of Arm-compatible CPUs finding homes in cloud datacenters. While the exact cores used by these chips may differ — most use Arm's Neoverse cores, but some, like Ampere have developed their own — most are using either the older ARMv8 or ARMv9 ISAs, ensuring that with few exceptions code developed on one should run without issue on the other. ®
Get our [14]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.theregister.com/2022/11/10/amd_96core_epyc/
[5] https://www.theregister.com/2024/07/15/amd_spills_the_beans_on/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
[9] https://www.theregister.com/2023/08/15/avx10_intel_interviews/
[10] https://www.theregister.com/2024/10/10/amd_epyc_turin/
[11] https://www.theregister.com/2024/10/15/samsung_hb3me/
[12] https://www.theregister.com/2024/09/24/intel_xeon_6p/
[13] https://www.theregister.com/2024/09/19/sifive_ai_accelerator/
[14] https://whitepapers.theregister.com/
Intel and AMD have been co-developing the x86-64 instruction for decades. But while end user workloads have enjoyed cross-compatibility between the two chipmakers' products, this has been far from universal.
"x86 is the de facto standard. It's a strong ecosystem, but it's one that really Intel and AMD have co-developed in a way, but an arm's length, and you know, that has caused some inefficiencies and some drift in portions of the ISA over time." AMD EVP of datacenter solutions Forrest Norrod said during a press briefing ahead of the announcement.
[1]
The introduction of advanced vector extensions (AVX) is the most obvious example of where compatibility across Intel and AMD platforms hasn't always been guaranteed.
[2]
[3]
For many years, those who wanted to take advantage of fat 512-bit vector registers have been limited to Intel platforms. In fact, AMD lacked support for AVX-512 until the [4]launch of Zen 4 in 2022, and even then it only supported it by double pumping a 256-bit data path. It wasn't until this year's Zen 5 [5]launch the House of Zen added support for a full 512-bit data path.
Going forward, Intel, AMD, and their industry partners aim to avoid this kind of inconsistency by converging around a more uniform implementation. To support this goal, the duo has solicited the help of Broadcom, Dell, Google, HPE, HP, Lenovo, Meta, Microsoft, Oracle, Red Hat, as well as individuals, including Linux kernel-dev Linus Torvalds and Epic's Tim Sweeney.
[6]
This advisory group will be tasked with reshaping the x86 ISA to improve cross-compatibility, simplify software development, and address changing demands around emerging technologies.
"We'll have, not only will we have the benefits of performance, flexibility and compatibility across hardware, we'll have it across software, operating systems and a variety of services," Intel EVP of datacenter and AI group Justin Hotard told us.
"I think this will actually enable greater choice in the fundamental products, but reduce the friction of being able to choose from those choices," echoed Norrod.
[7]
However, it'll be some time before we see the group's influence realized in products. Norrod emphasized that silicon development can take months if not years. As such it's "not something that's going to reflect into products, I don't believe, in the next year or so."
For end users, the benefits are numerous as in theory taking advantage of either Intel or AMD's products will require less specialization, something we're sure the hyperscalers will appreciate.
For the long-time rivals, however, the change could have major implications for the future development of the architecture. While the two chipmakers have caught up with each other on vector extensions, Intel still has its advanced matrix extensions (AMX) for CPU-based AI inference acceleration.
It remains to be seen whether these extensions will be phased out or if some version of them will eventually make their way into AMD's Epyc and Ryzen processors. We have no doubt that either team's SoC designers would relish the opportunity to reclaim all that die area currently consumed by the NPU.
"I don't think we want to commit to 'we're going to support this or not support this' in a time frame. But I think the intent is we want to support things consistently," Hotard said.
While Norrod and Hotard declined to comment on specific changes coming to x86, recent developments, particularly on Intel's side, give us some idea of the ISA's trajectory.
In June, Intel published an update to its proposed [8]x86S spec , a stripped down version of the ISA free of legacy bloat — most notably 32-bit and 16-bit execution modes. As we understand it, 32-bit code would still be able to run, albeit in a compatibility mode.
There's also the AVX10 spec that we [9]looked at last year, which made many of AVX512's more attractive functions. Under the new spec, AVX10 compatible chips will, for the most part, share a common feature set — including 32 registers, k-masks, and FP16 support — and minimally support 256 bit wide registers.
AVX10 is important for Intel which has transitioned to a dual-stack Xeon roadmap with P-and E-core CPUs, like Granite Rapids and Sierra Forest, the latter of which lacks support for AVX512.
[10]AMD pumps Epyc core count to 192, clocks up to 5 GHz with Turin debut
[11]Samsung's HBM3E has been a disaster, but there's a path back
[12]With Granite Rapids, Intel is back to trading blows with AMD
[13]SiFive expands from RISC-V cores for AI chips to designing its own full-fat accelerator
AMD's dense Zen C-cores don't suffer from this limitation, but can be switched to a double pumped 256-bit data path to achieve lower power AVX512 support. Whether Intel will push ahead with AVX10 or borrow AMD's implementation under the newly formed advisory group is another unknown, but given enough time, we can expect the two chipmakers to coalesce around a common implementation whether it be AVX, AMX or something else.
That's assuming, of course, that Intel and AMD can agree on how to address industry needs.
With that said, a more consistent ISA could help stave off the growing number of Arm-compatible CPUs finding homes in cloud datacenters. While the exact cores used by these chips may differ — most use Arm's Neoverse cores, but some, like Ampere have developed their own — most are using either the older ARMv8 or ARMv9 ISAs, ensuring that with few exceptions code developed on one should run without issue on the other. ®
Get our [14]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.theregister.com/2022/11/10/amd_96core_epyc/
[5] https://www.theregister.com/2024/07/15/amd_spills_the_beans_on/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/systems&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zw7mBe8-7pcEO11KTVUELgAAAIw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
[9] https://www.theregister.com/2023/08/15/avx10_intel_interviews/
[10] https://www.theregister.com/2024/10/10/amd_epyc_turin/
[11] https://www.theregister.com/2024/10/15/samsung_hb3me/
[12] https://www.theregister.com/2024/09/24/intel_xeon_6p/
[13] https://www.theregister.com/2024/09/19/sifive_ai_accelerator/
[14] https://whitepapers.theregister.com/
Re: Don't cast me in the role of Cassandra, but...
Baird34
Hi Cassie.
Re: Don't cast me in the role of Cassandra, but...
abend0c4
I prefer Sandra... Oh, what a giveaway!
Progress!
Anonymous Coward
Going 64-bit only (dropping 16-bit and 32-bit legacy silicon) as discussed in the "x86S spec" link, and as [1]mulled last year , makes good sense to me, especially now that those chips and systems aren't booting through some 16-bit PC BIOS anymore but through UEFI instead, straight into 64-bit operation.
ARM had the same idea [2]4 years ago with all new Cortex-A in its [3]Tocal Compute Solutions (TCS) being 64-bit only from last year (approx.), like the Cortex-X925, Cortex-A725, and Cortex-A520 (AFAIK).
8-bit, 16-bit, and 32-bit chips might still find uses in the tiniest, or least expensive, of computational devices though, just not as main CPUs in phones, tablets, laptops, desktops, workstations, servers, etc ..., IMHO.
Hopefully they also start considering 128-bit addressing in their reshaped ISAs, as needed for the Zettascale (and beyond)!
[1] https://www.theregister.com/2023/05/25/intel_proposes_dropping_16_bit_mode/
[2] https://www.theregister.com/2020/10/08/arm_32bit_support/
[3] https://newsroom.arm.com/blog/64-bit
Re: Progress!
Someone Else
Hopefully they also start considering 128-bit addressing in their reshaped ISAs, as needed for the Zettascale (and beyond)!
So the return of the Intel segment registers, then? Oh-comma-goodie!
Re: Progress!
Anonymous Coward
Aren't 16 and 32 bit modes implemented in microcode these days, using barely any silicon?
Don't cast me in the role of Cassandra, but...
... the usual point in history in which bitter rivals agree to cooperate is the moment they realise the jig is up.