Discussion Intel current and future Lakes & Rapids thread

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

IntelUser2000

Elite Member
Oct 14, 2003
8,051
2,854
136
You need hybrid bonding to get close to monolithic. Foveros has a smaller bump pitch than EMIB, which is probably why it's used here, but it's still not quite monolithic.
So Intel says on-die fabrics need 0.1pJ/bit, and Foveros requires 0.3pJ/bit. Still a fair bit higher, but organic interposers are over 1pJ/bit, and EMIB is slightly below 1pJ/bit.

When you are talking about datapaths for I/O, then it cannot be shut down as readily as the individual blocks do, because they need to meet QoS and bandwidth/latency requirements. Also because you need to serve every block that uses the bus. If you have 50 blocks on a bus, but only one is active, you still need to have the whole bus online.

It seems that on a higher level you can use things as power gating to lower power use, but they don't use it for say, the decoders as it's too latency critical.

So theoretically it should offer both faster on/off transitions for the chipset actually allow it to reach much lower power idle(and/or more often) and also reduce the absolute floor of power the communication line uses. This means the ~1.5W or so TDP of the on-package chipset is often reached even in very light load. Yes you can get that really low in idle, but it's very easy to knock it off that state.

That is theory of course. Atom didn't benefit from things being on-die until Silvermont when they updated to a proper on-die bus.

Unfortunately, I think you'll be disappointed, but I hope my pessimism ends up being incorrect.
This is an opportunity. I think there's a chance for them to improve this greatly, though still playing catch up at this point.

Also, good to know davidbepo is a crock.
 
Last edited:

IntelUser2000

Elite Member
Oct 14, 2003
8,051
2,854
136
If my estimation on the die size is roughly correct the total area (with empty space) is around 178 mm^2.
So the top left should be Intel4 8c+16c compute part. The tile below would be N4 IO.
The center part would be N3 iGPU but it has space for 384 EU so it either is:
2 media engine + 384 EU
or
2 media engine + 192 EU + 6 tensor processing core (TPC) or similar
The right lean tile would be N5 SOC.
No that's wrong. Many people have explained this over many pages.

Top left is 2+8. Bottom tiny die is GPU. Center large tile is SoC or basically what's called PCH in current terms. Right is I/O.

You are probably following the twitter feed of someone like Wildcracks who said the same thing about the center being the iGPU not SoC, but we discussed this a while ago. He's wrong, although a reasonable expectation.

And the numbers you are using aren't even from him but complete imagination. Arrowlake is 384EU, not Meteorlake.
 
Last edited:

Exist50

Senior member
Aug 18, 2016
610
543
136
It seems that on a higher level you can use things as power gating to lower power use, but they don't use it for say, the decoders as it's too latency critical.

So theoretically it should offer both faster on/off transitions for the chipset actually allow it to reach much lower power idle(and/or more often) and also reduce the absolute floor of power the communication line uses. This means the ~1.5W or so TDP of the on-package chipset is often reached even in very light load. Yes you can get that really low in idle, but it's very easy to knock it off that state.

That is theory of course. Atom didn't benefit from things being on-die until Silvermont when they updated to a proper on-die bus.
Oh there are plenty of theoretical advantages, don't get me wrong, but I'm not convinced any will actually get realized with Meteor Lake as rushed as it seems to be.

Top left is 2+8. Bottom tiny die is GPU. Center large tile is SoC or basically what's called PCH in current terms. Right is I/O.
You swapped the GPU and IO.
 

ASK THE COMMUNITY