Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads

[Tigerick]

Wildcat Lake (WCL) Specs

Intel Wildcat Lake (WCL) is upcoming mobile SoC replacing Raptor Lake-U. WCL consists of 2 tiles: compute tile and PCD tile. It is true single die consists of CPU, GPU and NPU that is fabbed by 18-A process. Last time I checked, PCD tile is fabbed by TSMC N6 process. They are connected through UCIe, not D2D; a first from Intel. Expecting launching in Q1 2026.

		Intel Raptor Lake U	Intel Wildcat Lake 15W?	Intel Lunar Lake		Intel Panther Lake 4+0+4
Launch Date		Q1-2024	Q2-2026	Q3-2024		Q1-2026
Model		Intel 150U	Intel Core 7	Core Ultra 7 268V		Core Ultra 7 365
Dies		2	2	2		3
Node		Intel 7 + ?	Intel 18-A + TSMC N6	TSMC N3B + N6		Intel 18-A + Intel 3 + TSMC N6
CPU		2 P-core + 8 E-cores	2 P-core + 4 LP E-cores	4 P-core + 4 LP E-cores		4 P-core + 4 LP E-cores
Threads		12	6	8		8
Max Clock		5.4 GHz	?	5 GHz		4.8 GHz
L3 Cache		12 MB		12 MB		12 MB
TDP		15 - 55 W	15 W ?	17 - 37 W		25 - 55 W
Memory		128-bit LPDDR5-5200	64-bit LPDDR5	128-bit LPDDR5x-8533		128-bit LPDDR5x-7467
Size		96 GB		32 GB		128 GB
Bandwidth				136 GB/s
GPU		Intel Graphics	Intel Graphics	Arc 140V		Intel Graphics
RT		No	No	YES		YES
EU / Xe		96 EU	2 Xe	8 Xe		4 Xe
Max Clock		1.3 GHz	?	2 GHz		2.5 GHz
NPU		GNA 3.0	18 TOPS	48 TOPS		49 TOPS

As Hot Chips 34 starting this week, Intel will unveil technical information of upcoming Meteor Lake (MTL) and Arrow Lake (ARL), new generation platform after Raptor Lake. Both MTL and ARL represent new direction which Intel will move to multiple chiplets and combine as one SoC platform.

MTL also represents new compute tile that based on Intel 4 process which is based on EUV lithography, a first from Intel. Intel expects to ship MTL mobile SoC in 2023.

ARL will come after MTL so Intel should be shipping it in 2024, that is what Intel roadmap is telling us. ARL compute tile will be manufactured by Intel 20A process, a first from Intel to use GAA transistors called RibbonFET.

 

[Win2012R2]

AVX10 is a desperate last ditch attempt by Intel to slow down AMD's AVX512 momentum, which totally isn't working

AVX10 currently attempts to implement 128b implementation of the 512b registers

They already ditched that, and they should ditch stupid 256b also - keep it double pumped like AMD, works great, same code - AVX10 is totally moronic, typical Intel idea that that maybe would have worked if they had monopoly and shipped lots of units of hardware supporting it, which won't start happening until 2026 (AVX10.2 - real version, not "prep" like AVX10.1 - who is going to support that???)

 

[OneEng2]

Not at all since AVX10 hardware isn't even shipping and first good variant 10.2 is only due 2026, if it even sells to have any meaningful presence - it also brings very little new good stuff worth creating 2nd path for even if it's relatively easy, very few people in the first place do AVX512, it's going to be come the lowest common denominator for a very long time.

The main driver for AVX512 is in servers anyway, if Turin gets real volume next year then it should dominate that space for a long time.

Intel APX will be (hopefully) a lot more successful as it brings real new meaty stuff to the table.


I reckon they will kill 256b also and do double pumping AMD styley. The whole AVX10 should be scrapped in lieu of whatever AMD and Intel agree on going forward in that new advisory group of theirs.

Seems like Intel and AMD are moving toward more cooperation in instruction set, not less. This is certainly good news for applications, compilers, and consumers.

 

[OneEng2]

True.


I think 128 is optional (and Intel may not implement that in NVL clients).

Intel would require EITHER a major update to the Atom based core, or to implement the 128b version of AVX10 in order for E Cores to execute the new AVX instructions. I have to wonder how effective this would be though.

 

[igor_kavinski]

I'm not. AMD's AVX-512 just got borked!

Once Intel clients have AVX10, no developer is gonna spend additional time maintaining two different branches just to support AMD's AVX-512.

Great job spreading FUD.

Intel® Advanced Vector Extensions 10.2 (Intel® AVX10.2) Architecture Specification

This document describes the Intel® Advanced Vector Extensions 10.2 Instruction Set Architecture.

www.intel.com

 

[Win2012R2]

Seems like Intel and AMD are moving toward more cooperation in instruction set, not less.

I think they will agree on APX, which is genuinely useful stuff (more general purpose registers is always good), and AVX10 is likely to be Intel only in my view.

I don't know if anybody else noticed but Intel is now bastardising AMX too - on future SKUs they got something AMX-AVX512 ops, possibly supporting wide 1024 bit tiles they've got in AMX

 

[Schmide]

No they aren't. Source: AnandTech

Excerpt: "AVX10, by default, will allow developers that recompile their preexisting code to work with AVX10, as new processors with AVX10 won't be able to run AVX-512 binaries as they previously would have."

Like I mentioned before, they aren't binary compatible (which is bad news for AMD).


Actually, they are. A clean slate design that benefits them and only them. Sounds like an excellent move by Intel.


I'm not. AMD's AVX-512 just got borked!


Once Intel clients have AVX10, no developer is gonna spend additional time maintaining two different branches just to support AMD's AVX-512.


Intel client market share is at around ~80%. They dictate terms in clients. Once AVX10 comes out, AMD's AVX-512 will not be the common denominator anymore. AMD has no choice but to follow suit sooner rather than later.

Go look up superset and subset. (repeat)

Everything that works on avx10 will work on AMD's avx512 minus the FP16 and xeon phi instructions.

Now down the road intel could introduce avx10.n (where n != 1, 2) that would break compatibility with avx512, but considering intel and AMD recently joined hands to form the "x86 ecosystem advisory group", I freaking doubt it.

Just stop diggin you're wrong.

 

[SiliconFly]

.

 

[igor_kavinski]

Just fyi, an excerpt form the Intel paper:
"This new ISA includes all the richness of the Intel® Advanced Vector Extensions 512 (Intel® AVX-512) with additional features and capabilities enabling it to seamlessly run across Performance-cores and Efficient-cores, delivering performance and consistency across all platforms."

They are solving their OWN problem. AMD doesn't have the problem of AVX-512 not working on their E-cores. And if a point comes where AVX10.2 support gives a decent enough boost, AMD will have a CPU ready with support for it within 2 to 3 years. AMD hasn't been sitting still since 2016.

 

[SiliconFly]

.

 

[Schmide]

Not much. For starters, X86S joint working group just got dissolved immediately after Pat's exit. They didn't even blink.

x86s was their internal get rid of previous compatibility, absolutely nothing to do with SIMD extensions.

 

[GTracing]

No they aren't. Source: AnandTech

Excerpt: "AVX10, by default, will allow developers that recompile their preexisting code to work with AVX10, as new processors with AVX10 won't be able to run AVX-512 binaries as they previously would have."

Like I mentioned before, they aren't binary compatible (which is bad news for AMD).

That's talking about AVX10.2 specifically. And even then AVX512 code would run on AVX10.2 CPUs.

 

[Win2012R2]

For starters, X86S joint working group just got dissolved immediately after Pat's exit.

It wasn't joint with AMD - it was Intel's only proposal that is now abandoned

 

[SiliconFly]

.

 

[Win2012R2]

It was. Lisa & Pat even posted a joint photo (w.r.t X86S) in their respective X/Twitter handles.

X86S was Intels internal project that was announced way before AMD/Intel created new advisory group, after that X86S was publicly abandoned by Intel

 

[Win2012R2]

To get legacy AVX-512 to run in AVX10.2 clients, a recompile is a necessary step.

AVX10 is as good as dead then, RIP

 

[Schmide]

Just to clarify, legacy AVX-512 should run natively only on P core only AVX10.2 CPUs like their Xeons. Not hybrids like Nova Lake. To get legacy AVX-512 to run in AVX10.2 clients, a recompile is a necessary step.

and just so you understand. That recompilation that is done for the avx10.2 clients should run without issue on any avx512 compatible processor.

 

[Win2012R2]

That recompilation that is done for the avx10.2 clients should run without issue on any avx512 compatible processor.

That can't be - avx10.2 should have things (including binary incompatibility) that don't work on avx512 only processor, unless you mean compiler creates two paths that will be correctly picked depending on processor it runs on

 

[SiliconFly]

.

 

[Schmide]

That can't be - avx10.2 should have things (including binary incompatibility) that don't work on avx512 only processor, unless you mean compiler creates two paths that will be correctly picked depending on processor it runs on

Every instruction in avx512 has a 512/256/128 pathway. ( just go play in the intrinsics guide ) A 10.2 compatible processor just has the 256/128 pathway with possibly methods for executing 512 bit instructions on a 10.2 compatible cpu.

Again 10.2 is a subset of avx512.

 

[Win2012R2]

Again 10.2 is a subset of avx512.

If 10.2 was a subset then why introduce it in the first place?

It must be a superset functionally, with some new stuff that is not present in AVX512, otherwise there is no point in it at all

 

[Win2012R2]

if the developer carefully chooses a subset of AVX10.2 that's fully backward compatible with AVX-512, then it may work.

Yes, and that subset has got a name - AVX512. This is what most developers would choose, from those handful that even know about its existence and are capable of using it.

 

[Schmide]

If 10.2 was a subset then why introduce it in the first place?

It must be a superset functionally, with some new stuff that is not present in AVX512, otherwise there is no point in it at all

There are a lot of avx512 instructions, like gather and mask, that are not in avx2. This is intel's way of providing a pathway to using those 256/128 instructions without providing a full 512 pathway.

avx512 is the superset and in actuality there are 21 versions of avx512.

 

[Win2012R2]

There are a lot of avx512 instructions, like gather and mask, that are not in avx2

Sure, but if AVX10 does not provide some of the AVX512 instructions then it does not make it a subset if at the same time it provides some stuff that isn't in AVX512 - they may intersect to a large degree, but being a subset is pretty much all in situation, that isn't the case here.

Masking should be in AVX10, is it not? Too valueable to drop surely

 

[Thunder 57]

No they aren't. Source: AnandTech

Excerpt: "AVX10, by default, will allow developers that recompile their preexisting code to work with AVX10, as new processors with AVX10 won't be able to run AVX-512 binaries as they previously would have."

Like I mentioned before, they aren't binary compatible (which is bad news for AMD).


Actually, they are. A clean slate design that benefits them and only them. Sounds like an excellent move by Intel.


I'm not. AMD's AVX-512 just got borked!


Once Intel clients have AVX10, no developer is gonna spend additional time maintaining two different branches just to support AMD's AVX-512.


Intel client market share is at around ~80%. They dictate terms in clients. Once AVX10 comes out, AMD's AVX-512 will not be the common denominator anymore. AMD has no choice but to follow suit sooner rather than later.

This isn't back in the day when Intel dictated SIMD with SSE/SSE2. AMD is a major player now. Nobody is going to exclude AMD support, especially since Intel is about two years away. That wouldn't be smart IMHO.

I think they will agree on APX, which is genuinely useful stuff (more general purpose registers is always good), and AVX10 is likely to be Intel only in my view.

I don't know if anybody else noticed but Intel is now bastardising AMX too - on future SKUs they got something AMX-AVX512 ops, possibly supporting wide 1024 bit tiles they've got in AMX

I agree. APX is more interesting to me than AVX10. One of the big pros everyone mentions with ARM is more GPR's, and APX will increase that fior the first time since x86-64.

 

[Markfw]

This isn't back in the day when Intel dictated SIMD with SSE/SSE2. AMD is a major player now. Nobody is going to exclude AMD support, especially since Intel is still years away. That would be comically stupid. This AMD doom and gloom is just fearmongering and that is why you are getting backlash. It's a bit surprising that Intel created AVX-512 and have had all this trouble with it.



I agree. APX is more interesting to me than AVX10. One of the big pros everyone mentions with ARM is more GPR's, and APX will increase that fior the first time since x86-64.

A couple of things I disagree with, but this is not the place to argue about them, but I will comment anyway.

Every business I have worked for in the last 40 years has ALL Intel desktops all over the place, including (for medical) multiple rooms that no one is in directly. This will greatly increase the said market share, but if exclude ALL of those the number from a consumer point of view I suspect is far greater than 24% for AMD and 76% for Intel.

AVX512 is used far more than a typical gamer would see, and many here I suspect are primarily gamers. Even excluding servers, I would guess that (also excluding server and gamers) AVX-512 is used in as much as 50% of the remaining boxes for work, drafters, scientific software, DC users. Its not dead at all. Why do you think Intel used to have it in consumer CPUs ? Only the Intel 10+++ made their CPUs run hot, and due to the inefficient design and implementation they had to run much slower when it was used, and they finally had to disable it to try and keep up with Zen3 (I think that was the generation when the 12xxx series came out.)

Please continue this if you want in an AMD thread, since so much of this is more AMD based than Intel based.