Intel Previews AVX10 ISA, Next-Gen E-Cores to get AVX-512 Capabilities

[T0@st]

Intel has published a preview article covering its new AVX10 ISA (Instruction Set Architecture)—the announcement reveals that both P-Cores & E-Cores (on next-gen processors) will be getting support for AVX-512. Team Blue stated: "Intel AVX10 represents a major shift to supporting a high-performance vector ISA across future Intel processors. It allows the developer to maintain a single code-path that achieves high performance across all Intel platforms with the minimum of overhead checking for feature support. Future development of the Intel AVX10 ISA will continue to provide a rich, flexible, and consistent environment that optimally supports both Server and Client products."

Due to technical issues (E-core related), Intel decided to disable AVX-512 for Alder Lake and Raptor Lake client-oriented CPU lineups. AMD has recently adopted the fairly new instruction set for its Ryzen 7040 mobile series, so it is no wonder that Team Blue is attempting to reintroduce it in the near future—AVX-512 was last seen working properly on Rocket and Tiger Lake chips. AVX10 implementation is expected to debut with Granite Rapids (according to Longhorn), and VideoCardz reckons that Intel will get advanced instructions for Efficiency cores working with its Clearwater Forest CPU architecture.



View at TechPowerUp Main Site | Source

 

[enb141]

So now blu ray will work again?

 

[Six_Times]

Does this mean AVX512 will be implemented again for Meteor Lake Ultra ?

 

[tabascosauz]

So now blu ray will work again?

BluRay had nothing to do with AVX. It was SGX that was full of security holes and Intel got rid of it.

 

[ncrs]

Does this mean AVX512 will be implemented again for Meteor Lake Ultra ?

Doesn't look like it, at least not the full AVX-512. According to Intel's enablement in the GCC compiler Meteor Lake, Arrow Lake and Lunar Lake are all without AVX-512 capabilities (indicated by lack of P_PROC_AVX512F).

 

[Assimilator]

Does this mean AVX512 will be implemented again for Meteor Lake Ultra ?

Nope, scuttlebutt is that this will only make an appearance in consumer CPUs with Lunar Lake, which is supposed to be their next great 15-generation hope for mobile in 2025. Considering 12th gen was meh and 13th and 14th "generations" have no new features, I'd be very surprised if this big a change actually happens on that timeline - especially considering Meteor Lake aka gen14 is a node shrink with chiplets and Intel hasn't said squat about it since January, except for trying to distract with their stupid branding change.

If MTL goes particularly poorly it will never make it to desktop (see also: Cannon Lake, Ice Lake) and that would set these projections back even further. Considering the only possible MTL benchmarks spotted in the wild have been for mobile parts I'm strongly suspecting this is the case, and Intel will just refresh gen13 on desktop and call it gen14, and these "gen14" desktop chips will desperately cram even more cores into an architecture that is long overdue for replacement. So if you thought Intel's CPU power consumption was bad before, hoo boy.

 

[AnotherReader]

Real World Technologies has an interesting discussion regarding this. One of the posts summarizes the changes:

The announcement from today about AVX10 contains only two facts:

1. AVX-512 has been renamed as AVX10

2. A subset of AVX-512 a.k.a. AVX10 has been defined, with 256-bit vector registers and 32-bit mask registers. This subset will be implemented in all future Intel CPUs after some date. The Intel documents describe how the support for this subset will be identified and what implications it will have for operating systems and for the porting of older applications.

In other words, next gen E-cores won't implement AVX-512; rather they will implement AVX10 which keeps the features of AVX-512 but decreases the vector width to 256 bits which is the same as regular AVX.

 

[Assimilator]

Real World Technologies has an interesting discussion regarding this. One of the posts summarizes the changes:


In other words, next gen E-cores won't implement AVX-512; rather they will implement AVX10 which keeps the features of AVX-512 but decreases the vector width to 256 bits which is the same as regular AVX.

That's the entire reason for this rename/rebrand (although I don't know where the "10" comes from): 512-bit instructions are just too large for efficient processing, so Intel wants you to forget they ever introduced AVX512. And honestly given that 256 bits is more than enough for most use cases, AVX10 aka AVX256 should be fine for quite a while.

 

[AnotherReader]

Surprisingly, TPU hasn't covered the biggest change to x86 since Hammer 20 years ago. Some of the more important changes are below:

Intel® APX doubles the number of general-purpose registers (GPRs) from 16 to 32.

Intel® APX adds conditional forms of load, store, and compare/test instructions, and it also adds an option for the compiler to suppress the status flags writes of common instructions

 

[TumbleGeorge]

Surprisingly, TPU hasn't covered the biggest change to x86 since Hammer 20 years ago. Some of the more important changes are below:

Mmm. In article has weblink to same page. When Intel decide to publish press release in TPU I think that all be shown here.

 

[AnotherReader]

Mmm. In article has weblink to same page. When Intel decide to publish press release in TPU I think that all be shown here.

My mistake. I read the content about the E cores; the summary missed the APX announcement.

 

[chrcoluk]

Intel is all over the place, they add something, they remove it, then they add again.

Also looks like its AVX 10.2 specifically that they will (re)add to consumer chips.

 

[ncrs]

Nope, scuttlebutt is that this will only make an appearance in consumer CPUs with Lunar Lake, which is supposed to be their next great 15-generation hope for mobile in 2025.

Do you have a reliable source for that claim? It's in direct contradiction to what Intel submitted to GCC with Lunar Lake still being at AVX2 level, and not AVX-512F.

 

[Assimilator]

Do you have a reliable source for that claim? It's in direct contradiction to what Intel submitted to GCC with Lunar Lake still being at AVX2 level, and not AVX-512F.

Like I said, it's rumour... unfortunately I can't find where I read it ATM. If I do I'll post it, but until then feel free to assume I'm making s**t up.

 

[dragontamer5788]

Do you have a reliable source for that claim? It's in direct contradiction to what Intel submitted to GCC with Lunar Lake still being at AVX2 level, and not AVX-512F.

"Scuttlebutt" is some weird English-slang for rumor. Speak American dang it! But in any case, "scuttlebutt" is an open admission that there's no reliable source. But its interesting to think about nonetheless.

------------

All in all, this AVX10 and APX all looks like a good plan. But heck, AVX512 was a good plan and good idea overall IMO, just Intel screwed it up royally and somehow AMD's Zen4 implementation is superior.

That's the entire reason for this rename/rebrand (although I don't know where the "10" comes from): 512-bit instructions are just too large for efficient processing, so Intel wants you to forget they ever introduced AVX512. And honestly given that 256 bits is more than enough for most use cases, AVX10 aka AVX256 should be fine for quite a while.

Just because the ISA is 512-bit doesn't mean that you have to lay out the fundamental circuit as 512-bit. AMD's 256-bit wide vector cores are executing AVX512 perfectly fine with high performance benefits.

In another example: AMD GCN is 2048-bit ultra-wide 64x32-bit GPU ISA, but was physically implemented with only 16x ALUs (aka; 512-bit wide physical implementation that executed 2048-bit code across 4-clock cycles). Etc. etc.

----------

My expectation is that this APX / AVX10 whatever stuff is good Intel Engineering, and that Intel's horrible management / business side hasn't figured out how to screw it up yet. But in practice, they will screw up this plan somehow.

 

[Minus Infinity]

AMD of course won't have this problem with their dense cores. Scheduling won't be an issue either.

 

[DemonicRyzen666]

"Scuttlebutt" is some weird English-slang for rumor. Speak American dang it! But in any case, "scuttlebutt" is an open admission that there's no reliable source. But its interesting to think about nonetheless.

------------

All in all, this AVX10 and APX all looks like a good plan. But heck, AVX512 was a good plan and good idea overall IMO, just Intel screwed it up royally and somehow AMD's Zen4 implementation is superior.



Just because the ISA is 512-bit doesn't mean that you have to lay out the fundamental circuit as 512-bit. AMD's 256-bit wide vector cores are executing AVX512 perfectly fine with high performance benefits.

In another example: AMD GCN is 2048-bit ultra-wide 64x32-bit GPU ISA, but was physically implemented with only 16x ALUs (aka; 512-bit wide physical implementation that executed 2048-bit code across 4-clock cycles). Etc. etc.

----------

My expectation is that this APX / AVX10 whatever stuff is good Intel Engineering, and that Intel's horrible management / business side hasn't figured out how to screw it up yet. But in practice, they will screw up this plan somehow.

AMD AVX512 is SLOW!

 

[mahirzukic2]

How come? Any sources?