Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)

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

Ajay

Lifer
Jan 8, 2001
16,094
8,116
136
IEC said:
That's setting yourself up for disappointment.

I don't expect both a 40% IPC gain (already very high) and a fMax boost in the same generation. If they manage to pull a rabbit out of a hat and complete a magic trick to do that, Zen 5 will be unobtanium.
Click to expand...
Eh, all that needs to happen is for *one* benchmark to increase by more than 30% and it's winner, winner, chicken dinner. All the leakers will simultaneously orgasm.
 
  • Haha
Reactions: Tlh97, inf64, Mopetar and 4 others
C

cherullo

Member
May 19, 2019
59
133
106
A few months back, an AMD patent about a op-cache that could spill it's contents into the L1I made the rounds in the forums:

Method and apparatus for virtualizing the micro-op cache - https://patents.justia.com/patent/11586441
Rather than dropping the evicted micro-operations, the evicted micro-operations are written to the conventional cache subsystem.
Click to expand...
There is a "pre-decode cache" which stores whether a cache line stores instructions or uops. There may be distinct pre-decode caches covering each cache level (L1I, L2, L3) or a single, global cache.
Since instructions are usually denser than uops, the patent lists some possibilities upon eviction of uops from the uop-cache: compression of immediate values in the uop cache entry, usage of two cache lines (two ways) simultaneously or just discard the decoded uops.
When uops are evicted from the L3, the patent doesn't say whether they should be written to memory. So this is volatile and not Denver-like.

While I was looking for it, I also found this:
Processor with multiple op cache pipelines - https://patents.justia.com/patent/11907126
Basically, the op-cache would be able to retrieve uops from two different addresses on the same clock. One possibility would be to fetch the instructions up to a branch and the instructions following the target address.
AFAIK current Zens can't do this (even for branches not taken), so branches do reduce the instruction throughput out of the uop-cache. Could this be what was called Zero-Bubble Branch Predictor in the Zen5 slides?
Another interesting possibility that Zen4 can't do is to fetch uops from different threads in the same cycle. This behavior can be steered by external policies (QoS) and how full each downstream uop queue is. Could make SMT even more efficient.

So, did we get any more information about it? Maybe LLVM or Linux kernel patches with related info?
Do you guys think that any of this made it into Zen5?
 
  • Like
Reactions: Elfear, Tlh97, moinmoin and 9 others
Markfw

Markfw

Moderator Emeritus, Elite Member
May 16, 2002
27,406
16,255
136
cherullo said:
A few months back, an AMD patent about a op-cache that could spill it's contents into the L1I made the rounds in the forums:

Method and apparatus for virtualizing the micro-op cache - https://patents.justia.com/patent/11586441

There is a "pre-decode cache" which stores whether a cache line stores instructions or uops. There may be distinct pre-decode caches covering each cache level (L1I, L2, L3) or a single, global cache.
Since instructions are usually denser than uops, the patent lists some possibilities upon eviction of uops from the uop-cache: compression of immediate values in the uop cache entry, usage of two cache lines (two ways) simultaneously or just discard the decoded uops.
When uops are evicted from the L3, the patent doesn't say whether they should be written to memory. So this is volatile and not Denver-like.

While I was looking for it, I also found this:
Processor with multiple op cache pipelines - https://patents.justia.com/patent/11907126
Basically, the op-cache would be able to retrieve uops from two different addresses on the same clock. One possibility would be to fetch the instructions up to a branch and the instructions following the target address.
AFAIK current Zens can't do this (even for branches not taken), so branches do reduce the instruction throughput out of the uop-cache. Could this be what was called Zero-Bubble Branch Predictor in the Zen5 slides?
Another interesting possibility that Zen4 can't do is to fetch uops from different threads in the same cycle. This behavior can be steered by external policies (QoS) and how full each downstream uop queue is. Could make SMT even more efficient.

So, did we get any more information about it? Maybe LLVM or Linux kernel patches with related info?
Do you guys think that any of this made it into Zen5?
Click to expand...
Zen 5 was sampling months ago, no way any of that is in it. Zen 6, maybe even Zen 7 is where it might be.
 
L

leoneazzurro

Golden Member
Jul 26, 2016
1,114
1,867
136
biostud said:
Since 12 Gen core laptops are still being sold sold I think we can find Zen 4 laptops for a foreseeable future.
Click to expand...
True, I just got a MSI katana 15 with Alder Lake and a 4070 for 1100€, these machines and the Zen4 are still very capable so with the right pricing (and the fact there will be reduction of the costs of N5 and N4 processes with time, they will easily occupy the lower end/mainstream part of the market.
 
  • Like
Reactions: Tlh97 and biostud
A

Ajay

Lifer
Jan 8, 2001
16,094
8,116
136
Markfw said:
The leaker that said 39% said it was in one specific benchmark. So ????
Click to expand...
So that one person, if that's the number - will prove that he actually has an excellent source compared to the rest. The rest will still boast about getting it right because they have held 8 different positions on desktop Zen5 cpus and will claim victory - aka, that one piece of spaghetti actually did stick to the wall.
 
Last edited:
  • Like
Reactions: Tlh97, Fjodor2001 and Thibsie
T

Timorous

Golden Member
Oct 27, 2008
1,989
3,918
136
  • Like
Reactions: Tlh97 and Joe NYC
F

Fjodor2001

Diamond Member
Feb 6, 2010
4,636
748
126
Timorous said:
8c client, 16c server
Click to expand...
Why use 2x8c instead of 1x16c, for the 16c client CPU variants of Zen6?

Assuming there will be 16c CCD of Zen6 available anyway, why not use them on client too? Also opens up for 2x16c on client CPUs, and 1x16c + 1x8c.
 
Last edited:
  • Like
Reactions: Tlh97
T

Timorous

Golden Member
Oct 27, 2008
1,989
3,918
136
Fjodor2001 said:
Why use 2x8c instead of 1x16c, for the 16c client CPU variants of Zen6?

Assuming there will be 16c CCD of Zen6 available anyway, why not use them on client too? Also opens up for 2x16c on client CPUs, and 1x16c + 1x8c.
Click to expand...

Clockspeed, yields, node? 8c could be on an older node than 16c and 32c so would be quite a bit cheaper. V-cache compatibility.

Those are just off of the top of my head.
 
  • Like
Reactions: Tlh97 and Mopetar
Thunder 57

Thunder 57

Diamond Member
Aug 19, 2007
4,294
7,101
136
Fjodor2001 said:
Why use 2x8c instead of 1x16c, for the 16c client CPU variants of Zen6?

Assuming there will be 16c CCD of Zen6 available anyway, why not use them on client too? Also opens up for 2x16c on client CPUs, and 1x16c + 1x8c.
Click to expand...

Maybe they can only do 16 cores with dense variants which would hurt performance in desktop models.
 
S

StefanR5R

Elite Member
Dec 10, 2016
6,851
11,029
136
Apparently it's not just 8c/16c/32c CCDs, but 8c/16c/32c CCXs even.

As for the client CCDs, remember that it has been claimed that Zen 6 desktop will no longer be server derived, but mobile derived.
Regarding client CCXs, the larger and the more complex the last level cache, the higher tends to be its latency.

Also notable is that InstLatX64 claims that EPYC 9006 is on socket SP7.
 
adroc_thurston

adroc_thurston

Diamond Member
Jul 2, 2023
8,610
11,325
106
  • Like
Reactions: Tlh97, Joe NYC, Kepler_L2 and 1 other person
You must log in or register to reply here.

TRENDING THREADS

COMPANY
RESOURCES
FOLLOW
Top Bottom