• 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 Zen 6 Speculation Thread

Page 324 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
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.
 
Last edited:
AMDK11 said:
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.
Click to expand...
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.
 
Hulk said:
Okay, I take it back! Zen 5 didn't show the improvement "some" were hoping for.
Click to expand...
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.
 
Hulk said:
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.
Click to expand...
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).
adroc_thurston said:
oh it did much more than that, an absolute murder-machine in server w/l's.
Brutalized Genoa in a really funny way.
Click to expand...
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.
adroc_thurston said:
Game code is just inherently not very parallel-friendly.
Click to expand...
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 said:
UE5 is very very very brand new.
Click to expand...
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.

OneEng2 said:
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.
Click to expand...
adroc_thurston said:
Game code just isn't made to be parallel. It's interactive.
Click to expand...
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.
 
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.
 
OneEng2 said:
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.
Click to expand...
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.
 
Last edited:
AMDK11 said:
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.
Click to expand...
Just let an AI agent game for you 😛
 
AMDK11 said:
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.
Click to expand...
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.
 
Yes, there are bottlenecks to game engines, but they are well known and generally not cou limited. That's why people benchmark at lower resolution.

But I suspect that even the rendering is hampered by lots of legacy thinking.

Graphics are inherently easy to parallelize. Sure, you can't render ahead in all situations any more than you can branch predict correctly all the time. At a smaller time scale, you can absolutely predict with pretty good certainly what the next frames will be. You can also render ahead in the most probable cases.

It's silly to suggest that game engines can't be made core scalable imo.

The engineering question is how to make the juice worth the squeeze
 
Hulk said:
Very true, but they CAN average 1 baby/month for 9 months!
Click to expand...
But who wants 9 babies? It's a labored analogy at this point. The point is you probably only want one (at a time) and parallelism doesn't get that over with any sooner.

If the simulation/game code runs even on Switch at 60hz, what incentive do developers have to break game systems into thread-safe subsystems that can operate in parallel? Pretty much none...
 
gdansk said:
But who wants 9 babies? It's a labored analogy at this point. The point is you probably only want one (at a time) and parallelism doesn't get that over with any sooner.

If the simulation/game code runs even on Switch at 60hz, what incentive do developers have to break game systems into thread-safe subsystems that can operate in parallel? Pretty much none...
Click to expand...
My post had no intended meaning beyond humor.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top