Well, the PMC document that was linked here confirms dispatch to be 8-wide. Funnily enough similar entry for Zen5 says 6-wide but lists 8 events to track, so I guess that was a typo there (Zen5), but who knows. Printscreen from Zen6 doc:
Zen6 could enable both decoder clusters for ST mode, thus enabling 8-instruction decoding beyond SMT mode.
This is entirely feasible.
I also think that L1-I of at least 48KB 12-Way is also quite feasible in Zen6. From what I understand, the 32KB L1-I capacity is a bigger limitation for the Zen5 than the same ITLB as the Zen4. However, I suspect the ITLB will also be larger in the Zen6.
Whether this will happen depends on AMD's priorities and goals.
Edit:
Judging by the redesigned ALU scheduler, it's unlikely AMD will be able to count on subtle changes and improvements, as Intel is constantly in flux. AMD needs to make bold and consistent changes and improvements in this race. Zen5 was just a starting point.
I could be wrong, but I have a feeling Zen6 will be a solid generation.
This is entirely feasible.
I also think that L1-I of at least 48KB 12-Way is also quite feasible in Zen6. From what I understand, the 32KB L1-I capacity is a bigger limitation for the Zen5 than the same ITLB as the Zen4. However, I suspect the ITLB will also be larger in the Zen6.
Whether this will happen depends on AMD's priorities and goals.
Edit:
Judging by the redesigned ALU scheduler, it's unlikely AMD will be able to count on subtle changes and improvements, as Intel is constantly in flux. AMD needs to make bold and consistent changes and improvements in this race. Zen5 was just a starting point.
I could be wrong, but I have a feeling Zen6 will be a solid generation.
Last edited:
Hulk
Diamond Member
- Oct 9, 1999
- 5,226
- 3,857
- 136
From what I remember of the interview with the chief Zen 5 architect, Zen 5 is basically setting the table for Zen 6, which will exploit more fully the changes to Zen 5. This would make sense as to why Zen 5 did not show the lift we were hoping for.
DrMrLordX
Lifer
- Apr 27, 2000
- 23,114
- 13,215
- 136
adroc_thurston
Diamond Member
- Jul 2, 2023
- 7,886
- 10,601
- 106
oh it did much more than that, an absolute murder-machine in server w/l's.
Brutalized Genoa in a really funny way.
Hulk
Diamond Member
- Oct 9, 1999
- 5,226
- 3,857
- 136
Okay, I take it back! Zen 5 didn't show the improvement "some" were hoping for.
I'm assuming "some" means gamers.
It's mainly because 20 years after the first dual core PC CPU (and 20 years after the first tri core CPU console) most game engines are somehow still predicated on single threaded performance bottlenecking the render pipeline.
Supposedly Unreal Engine is making a big push to fix that, but that won't be done till UE6 lands, and gawd only knows what the state of multithreading is like elsewhere.
adroc_thurston
Diamond Member
- Jul 2, 2023
- 7,886
- 10,601
- 106
I remember this as well and always kind a wondered what exactly was meant by it.
I also distinctly remember people being disappointed about the desktop performance boost (ie "Zen 5% comments).
AMD just got smart IMO. DC focus was incredibly smart. Let Intel dominate all the low margin markets, and take away the cream and honey.
I don't believe that. I think that game code suffers from a legacy of decades of tools and engines that were not thread friendly. It is much much more difficult to design a system for n-threads than 1 thread... and even with many n-threaded systems, the primary GUI thread gets bottlenecked.
I think if system architects went at a game engine from the ground up with the explicit purpose of scaling with the number of cores, it is totally possible.
adroc_thurston
Diamond Member
- Jul 2, 2023
- 7,886
- 10,601
- 106
UE5 is very very very brand new.
Game code just isn't made to be parallel. It's interactive.
How much code base is shared in UE5 with UE4/3/2? (This is an honest question I would love to know....but the point is alot of code is likely to be legacy to support legacy things)
They have alot of optimization left on the table, that can be seen in some of the roadmap items from now through 6.0.
This is so true.
Is there room for improvement? Most likely yes in alot of engines.
But it seems like that improvement can only go so far to ensure the world functions coherently over time. (At least for FPS game types, etc).
This is similar to OneEng2's example, eventually a realtime interface has to have some synchronzation to be usable and prevent issues. (This is my somewhat laymans description, I dont know if that is some type of law or just a complexity thing... if Im wrong here then cool Id love to learn more around this topic as its not really something I deal with directly)
Most code development I see ends up alot like this: Im not changing anything if there isnt a problem to be fixed or a feature to be added.
This happens because of time to value constraints.
Sebbi's paper linked above is a prime example of incremental changes made w/o really fixing baggage. Man that was somewhat grim from the baggage perspective.
Thunder 57
Diamond Member
- Aug 19, 2007
- 4,204
- 6,991
- 136
I remember running Doom 1016 on 2C just for fun and it ran surprisingly well. Doom Eternal ran well on low end hardware too. Then we got TDA that needs much better hardware. Adding a bunch of pointless fodder enemies to demonstrate the awesome shield and reource harvest probably didn't help. And don't get me started on BF, those games makes excellent use of more cores.
adroc_thurston
Diamond Member
- Jul 2, 2023
- 7,886
- 10,601
- 106
More relevant is the amount of threads available to developers. 6 for PS4, 13 for PS5, 16 for PS6 (and 8 for the handheld).
9 pregnant women can't make a baby in 1 month. Some tasks have limitations to how parallel they can go
You could build a software renderer.
Or you could work backwards from "embarrassingly parallel" and come up with non-rendering gameplay tasks (eg. simulation, AI) that scale well with core count. Would probably need to be a task with poor uniformity or you would more than likely just throw it on a compute shader.
I'm not sure, so forgive me if I'm wrong. Isn't it true that games inherently achieve low IPCs due to their interactivity, and changes during gameplay are dynamic and unpredictable due to the freedom of action? So synchronization must be occurring, and the core spends most of its cycles waiting for the player's next move.
The core cannot predict the player's next move and prepare the next frames of the scene because you can change what is happening in the scene at any time, so the core waits for further instructions.
The core spends a really large number of cycles waiting for player movement and instructions needed to draw the next frames of the scene.
The core cannot predict the player's next move and prepare the next frames of the scene because you can change what is happening in the scene at any time, so the core waits for further instructions.
The core spends a really large number of cycles waiting for player movement and instructions needed to draw the next frames of the scene.
Last edited:
biostud
Lifer
- Feb 27, 2003
- 20,010
- 7,100
- 136
I'm sure it's a hard thing to do, but whatever interactivity they need doesn't need to be infinitely fast, as long as it doesn't take more than 1ms it shouldn't be a problem right?
As long as frame times aren't affected I don't see why interactivity would preclude parallelization by itself.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter