• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Question Raptor Lake - Official Thread

Page 74 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Hulk

Diamond Member
Since we already have the first Raptor Lake leak I'm thinking it should have it's own thread.
What do we know so far?
From Anandtech's Intel Process Roadmap articles from July:

Built on Intel 7 with upgraded FinFET
10-15% PPW (performance-per-watt)
Last non-tiled consumer CPU as Meteor Lake will be tiled

I'm guessing this will be a minor update to ADL with just a few microarchitecture changes to the cores. The larger change will be the new process refinement allowing 8+16 at the top of the stack.

Will it work with current z690 motherboards? If yes then that could be a major selling point for people to move to ADL rather than wait.
 
They are going to have to because AMD has it.
Intel made that decision many years ago and will be sticking with it at least until 2030.

Meteor Lake, Arrow Lake, Luna Lake and Nova Lake e cores((Gracemont/Crestmont/Skymont/Darkmont) will not incorporate AVX512

This dessition was made may years ago and they just don't care that AMD has incorporated that ISA on their CPU design. It's a niche product that helps IA and other programs. AMD just incorporated because they use the same Chiplet from desktops to high end servers so it makes financial sense for them(because they have a larger pool of chiplets that they can bin)
 
Last edited:
No, but Alder Lake Clearly chokes when it only has 2 MiB per core as clearly seen on the Benchmark I posted(If you would like to dispute that you can take that with techspot)

That just shows that AMD Built Zen with plenty of Cache.

Yes, with Zen 2/Game Cache slogan in the foreground quite logically. :grinning:

AMD 3D V-Cache on Desktop, Game Cache GTI Turbo etc.

Yes we now, Large L3 Cache it can bring great benefit in various server or HPC applications.

The more L3 Cache the better, but however it is much better to increase the significantly faster L2 cache=Zen 4.

 
As previously announced, as the successor to Intel’s existing Knights Corner (1st generation Xeon Phi), Knights Landing makes the jump from using Intel’s enhanced Pentium 1 (P54C) x86 cores to using the company’s modern Silvermont x86 cores, which currently lie at the heart of the Intel’s Atom processors. These Silvermont cores are far more capable than the older P54C cores and should significantly improve Intel’s single threaded performance. All the while these cores are further modified to incorporate AVX units, allowing AVX-512F operations that provide the bulk Knights Landing’s computing power and are a similarly potent upgrade over Knights Corner’s more basic 512-bit SIMD units.
source:
The Forest line is for cloud, not HPC. Cloud cares far more about int performance than fp.
 
Intel made that decision many years ago and will be sticking with it at least until 2030.

Meteor Lake, Arrow Lake, Luna Lake and Nova Lake e cores((Gracemont/Crestmont/Skymont/Darkmont) will not incorporate AVX512


What decision? There is zero info about AVX support on Skymont and Darkmont. If Skymont is a big architecture upgrade over Gracemont I can see them adding AVX512 to have a parity with the big cores. Remember prior to Gracemont Intels Atom didn't even support AVX2.
 
What decision? There is zero info about AVX support on Skymont and Darkmont. If Skymont is a big architecture upgrade over Gracemont I can see them adding AVX512 to have a parity with the big cores. Remember prior to Gracemont Intels Atom didn't even support AVX2.

Or alternatively, improve thread director and work with OS schedulers so that little cores don't need AVX512. This was possibly the original intention, seeing as AL and RL big cores have physical AVX512 eating up gobs of die area.
 
Intel made that decision many years ago and will be sticking with it at least until 2030.

Meteor Lake, Arrow Lake, Luna Lake and Nova Lake e cores((Gracemont/Crestmont/Skymont/Darkmont) will not incorporate AVX512
Nova is aiming for 2025/2026. That is a far cry from "at least until 2030". Nova is supposedly a huge architecture change (biggest change since Core), do you have evidence that it won't have AVX-512? Or that they won't fix the scheduler problem, or that they won't have a AVX-512 chiplet?

I do find it humorous to watch people who bashed AVX-512 now claim it is great and those who claimed AVX-512 is great now say it is niche.
 
What decision? There is zero info about AVX support on Skymont and Darkmont. If Skymont is a big architecture upgrade over Gracemont I can see them adding AVX512 to have a parity with the big cores. Remember prior to Gracemont Intels Atom didn't even support AVX2.
It's just Not going to happen.
 
Nova is aiming for 2025/2026. That is a far cry from "at least until 2030". Nova is supposedly a huge architecture change (biggest change since Core), do you have evidence that it won't have AVX-512? Or that they won't fix the scheduler problem, or that they won't have a AVX-512 chiplet?

Why are we even debating this? AVX-512 Is Dead for Client. You Will have to pay it to Unlock it on Xeons(SDSi)
 
Zen 4c has it...
Like I said they will put it in Atoms. I'm sure PR hates it that AMD has AVX-512 but the client CPUs don't.
It's certainly an interesting turn of events. Intel used to add more and more instructions while AMD refrains to add its own, instead seeking to catch up after some time. Now suddenly AMD finds itself supporting one of Intel's latest instructions (ignoring AMX) across its whole upcoming product range at a time Intel itself deactivated it (client) or appears to make it pay-more-to-unlock (server).
 
It's just your hope it won't happen, you have to make it clear.
It's a business decision that Intel has made that will be implemented through Software Defined Silicon(SDSi). First implementation will be on Sapphire Rapids-SP, SPR-X.

How many Vendors or Individuals are willing to pay for a Feature they don't need/know about on Laptops and Desktops? They just fuse the AVX-512 FPU Units and call it a day.
 
They could have done it like in Tiger Lake, one AVX512 FPU Register. But then they would have have to redesign the Golden/Raptor Cove/Redwood Cove for each segment(Server and Client), but it's cheaper to design one single core and just segment it.

It still takes up quite a bit of space even not adding 512-bit vector unit like they do on server. You still need the extra space for registers and stuff you know? Sunny/Willow Cove having large FPU block for AVX-512 is despite the fact it physically doesn't have 512-bit units and is same as Skylake client having 2x-256.

The fact that it's not added uniformly across the product line suggests 512-bit vector is the point where it's getting a bit too large in terms of power use and area.

Intel made that decision many years ago and will be sticking with it at least until 2030.

Oh almighty nicalandia, have mercy on us! Perhaps in your infinite graciousness can tell us what's in store for the world in 10 years?
 
Last edited:
i wouldn't say that at all, scalar over SIMD sure but then things like TLS throughput still matter alot.

Gracemont is AVX2 but with 128-bit vector units rather than 256-bit like Sandy Bridge and onwards. Being AVX2 it supports FMA but it would take 2 cycles.

Or alternatively, improve thread director and work with OS schedulers so that little cores don't need AVX512. This was possibly the original intention, seeing as AL and RL big cores have physical AVX512 eating up gobs of die area.

It will be quite difficult I imagine. It's like making Hyperthreading have no losses in single threaded workloads. You can minimize it and they have done a damn good job since Nehalem but it's not 100%.

It's worse here because you have the potential of causing application crash. You can change some newer ones to support it but older ones won't and Intel will get a lot of flack for it. That's what happens on a general purpose chip like a CPU.

Or that they won't fix the scheduler problem, or that they won't have a AVX-512 chiplet?

When you say "scheduler problem" you mean regarding two cores in a chip with different ISA's?

Again that's a very, very difficult if not almost impossible problem. Because when the application expects AVX-512 but some cores don't have it, it'll crash. Yes you can update the newer ones but you'll inevitably run into ones that don't. And you know automated approaches can't do 100% and require manual intervention for lots of scenarios.

The easiest way is down the line E cores eventually have AVX-512. I wouldn't be surprised if they reduce the ST gap between E and P cores to 15-20%. When the cores get that powerful maybe they'll get an upgrade to 256-bit units and they can add AVX-512.
 
Last edited:
I can see a scenario where, on the next big node/density jump, they add a half throughput avx-512 unit to the mont cores. The density increase allows them to afford to add it to the monts and keep the 4 to 1 size ratio with the coves that will grow even larger as they continue to fight for parallelism and a larger out if order window.
 
Sometime back there was a good discussion in RealWorldTech about this subject RealWorldTech

Linus is saying exactly what my intuition assumed would be the case, that there isn't a fundamental problem, and at a high level it actually looks simple, but it's still novel and will take time to get right.

Besides that, Linus takes umbrage with Intel's approach to big.LITTLE because the "throughput cores" lack the "throughput vector extension" while the "non-throughput cores" have the "throughput vector extension." I'm not sure I totally agree with him here; there are different types of throughput, but I get where he's coming from: with a high enough ratio of small to big cores, you could get into a situation where you lose performance if you use AVX 512.
 
Again that's a very, very difficult if not almost impossible problem. Because when the application expects AVX-512 but some cores don't have it, it'll crash.
AMD has a patent where such unsupported instructions would be caught and the process transparently moved to a core supporting it. This would move some of the scheduling complexity into the hardware which has a better picture of its own resources. But I'm not sure how feasible such a mixed approach is in today's OS ecosystem where all software schedulers expect to have complete control.
 
Average Performance of 25 entries Geekbench 5 for Raptor Lake 13900/K/KF CPUs


Single-Core Score: 2,208

Crypto Score: 5,312

Integer Score: 1,915

Floating Point Score: 2,324


Intel Core i9-13900K




















Intel Core i9-13900KF






Intel Core i9-13900



 
Last edited:
Average Performance of 5 entries Geekbench for Raptor Lake 13700K/KF CPUs


Single-Core Score: 2,055
Crypto Score: 4,656
Integer Score: 1,791
Floating Point Score: 2,195

13700K/KF





 
Average Performance of entries Geekbench 3 for Raptor Lake 13600K CPU


Single-Core Score: 1,964

Crypto Score: 4,868
Integer Score: 1,710
Floating Point Score: 2,065

Intel 13600K


https://browser.geekbench.com/v5/cpu/17122807



 
What decision? There is zero info about AVX support on Skymont and Darkmont. If Skymont is a big architecture upgrade over Gracemont I can see them adding AVX512 to have a parity with the big cores. Remember prior to Gracemont Intels Atom didn't even support AVX2.
There is no place for AVX512 in the current Golden + Gracemont scheme. The E-cores are not power efficient, but area efficient. Thus inflating the FPU box with an AVX512 support defeats the area efficiency.

Intle would need to change the roles of their hybrid cores. Either make the E-cores power efficient (by not clocking them so damn high) or cut the fat from the P-cores and make them more area efficient.
 
There is no place for AVX512 in the current Golden + Gracemont scheme. The E-cores are not power efficient, but area efficient. Thus inflating the FPU box with an AVX512 support defeats the area efficiency.

Intle would need to change the roles of their hybrid cores. Either make the E-cores power efficient (by not clocking them so damn high) or cut the fat from the P-cores and make them more area efficient.
I think when 3d stacking cores come, they won't need to use E-cores at all because with 3d stacking, area efficiency is much less concern, and that's the only reason they went to big/little design, they can't create effectively more than 8 P cores with current 2d design.
 
Back
Top