With the important disclaimer that this obviously is different for everyone. I play a lot of simulation/strategy games (like Cities: Skylines and Hearts of Iron) and most of the games I play actually are CPU bound, especially in later stages of the games.
Mainly because they're relatively simple graphically but they want to run at super high framerates, so the bottleneck is the CPU feeding the GPU each frame.
Which is basically memory bandwidth problem, which a large L3 cache helps a lot with. I've seen the same things with ClickHouse, having a larger L3 cache and fewer cpu cores can increase performance significantly.
Doesn't a lot of optimization target making your code and data more cache friendly because memory latency (not bandwidth?) kills performance absolutely (between other things like port usage I guess)?
If something is in L3 it is better for CPU "utilization" than stalling and reaching out to RAM. I guess there are eventually diminishing returns with too much cache, but...
I certainly don't care to do it, but running FPS above your frame rate can reduce latency if the frame buffering policy is reasonable (or you don't mind tearing). The difference isn't very big, especially if you're at 240Hz, but getting stuff to the display one frame sooner makes a difference.
But I've heard of triple buffering setups where you're displaying the current frame, and once you have a complete next frame, you can repeatedly render into the second next frame, but the next frame isn't swapped. In that case, it's hard to argue for any gain, since your next frame is way old when it's swapped to current.
Some rendering systems will do double buffering where the render is scheduled to start just in time to finish with a small margin before vBlank. If you've got that tuned just so, that's almost the same latency benefit as running unlocked, but if rendering takes too long you have a stutter.
If you spend as much time in online games as some people do (it's not rare to find a steam account with thousands of hours in GTA 5), it would absolutely make sense to get a new CPU which will save you 10-15 minutes of waiting time per day.
Also, "perfect storm of bad coding" is the norm for games, and not the exception, no?
Interesting outlier: Factorio and probably other games from this genre.
I usually upgrade my CPU just to prevent it from becoming a bottleneck (that's the official version, I very often buy technology for the sake of having cool new technology, who am I kidding). So a CPU upgrade hadn't been something that made a game "playable" for me since GPUs became a thing. But when I got my 7800X3D, that was the difference between having reached a limit with my Factorio megabase and being able to keep building it bigger!
Also, since the simulation in that game has to churn through a lot of data in every tick, it's also a rare case in general where RAM speeds have a visible effect.
You would think that, but multicore programming is really hard. Balancing all the tasks of your game across available cores is not easy, and given the intense crunch with which games are developed, there's often no time to do this properly. So single-thread performance is still very important, especially for newer titles, which is why Intel was still considered the best CPU for gaming (which is now changing, but mostly due to the stability problems).
So this very much depends on which games you test and how you configure them graphics-wise. AMD was accused of heavily skewing their initial marketing numbers when introducing Zen5, almost exclusively testing with older games and testing them with very weak graphics cards to make them GPU-bound. In this case, MSI only tested with three games, which is a tiny, tiny data point. Channels like HardwareUnboxed test with up to 30 games to get a complete picture of the performance.
How does the domination of a few big game engines(unity/unreal) change this? I get the impression that they handle more and more of the actual compute intensive stuff, and 'nobody' writes their own engines anymore?
So then the economy of scale changes it a bit, and maybe they can make abstractions which use many cores under the hood, hiding the complexity?
Yes, certain problems are very typical for Unreal and can be seen in many games using it, especially stutters from on-demand shader compilation and "traversal stutter" when entering new areas (so mostly problems with on-demand texture loading). These problems can be fixed, but there's no magic bullet, it simply requires a lot of work, so often this is relegated to later patches (if even that).
But there are certain games which in addition are heavily bound by single-thread performance, although they are using Unreal, probably the most prominent lately being Star Wars Jedi Survivors, which isn't fixed to this day. You can watch Digital Foundry's video for details: https://www.youtube.com/watch?v=uI6eAVvvmg0
Why exactly this is no one can say apart from the developers themselves.
> Yes, certain problems are very typical for Unreal and can be seen in many games using it, especially stutters from on-demand shader compilation and "traversal stutter" when entering new areas (so mostly problems with on-demand texture loading).
This problem is so obvious and widespread now, I wish there was a toggle/env var where I could decide I'm willing to have longer loading-screens rather than in-game stutters/"magically appearing objects", just like we had in the good old days.
Some games use a small percentage of my available VRAM and/or RAM, yet they decide to stream in levels anyways, regardless of it not being needed for any resource-usage reasons.
I don't think the problem is that easy to solve in general. For a lot of modern games, there are only two amounts of total memory that would really matter: enough to run it at all, and enough to hold all game assets uncompressed. The former is usually around 4-16 GB depending on settings and the latter is often over 200 GB.
Very few gamers have that much RAM, none have that much VRAM. Many assets also aren't spatially correlated or indexed, so even though a whole "level" might be discrete enough to load specifically, the other assets that might be needed could still encompass nearly everything in the game.
For these games, amounts of memory in between those two thresholds aren't especially beneficial. They'd still require asset streaming, they'd just be able to hold more assets at once. That sounds better, and in some cases might just be, but really the issue is boiling down to knowing what assets are needed and having already loaded them before the player sees them. That's a caching and prediction problem much more than a memory size problem.
> How does the domination of a few big game engines(unity/unreal) change this? I get the impression that they handle more and more of the actual compute intensive stuff, and 'nobody' writes their own engines anymore?
You still have to know what you're doing. Cities: Skylines 2 is a good example, as the first installation had awful performance when playing bigger cities, and it wasn't very good at parallelizing that work.
For the second game, they seem to have gone all in with Unity ECS, which changes your entire architecture (especially if you use it wholesale like developers of Cities: Skylines did), which is something you have to explicitly do. Now the second game is a lot better at using all available cores, but it does introduce a lot of complexity compared to the approach they took in the first game.
If you go by number of games and console ports, sure. But those you play once or wait for a good price and play the story for 8-20h.
If you look at consistent player numbers, some top games are CS2, Valorant, WoW, FXIV, LoL and Dota2.
Competitive FPS are CPU bound as they are easy to run, but people want the highest framerates possible due to new 200+hz screens and general player input is better with higher framerates.
MMOs are CPU bound once you get into large groups and into big towns with lots of players, even brand new MMOs like Throne and Liberty.
MOBAs Im not sure, but in general, same with FPS games. More framerates = good for player input. These games are not a single player game you lock at 30 or 60 frames.
Flight simulator games (i.e. Digital Combat Simulator) tend to be CPU bound, though, depending high-end VR or having enough monitors with enough pixels can quickly become GPU-limited, the underlying simulation, systems modelling, sensor simulations, AI, etc, will still all be CPU limited.
The key metric for gaming is how to split a certain budget between GPU and non-GPU components, and where the sweet spots are on that budget curve. The trend in recent years have been to always go for a cheaper cpu and expensive GPU, but not too cheap.
The impact of going from a non-X3D to X3D CPU is incredible in that game. I could be off on the details, but I recall benchmarks showing that just switching to an X3D has a much larger impact than jumping multiple generations of GPU. I get like 120 FPS with a 5600X and RTX 3080. I've been dreaming of a 9800X3D based build when it comes out, but realistically don't have the time to actually play.
A lot of games are, especially MMOs. Single-threaded performance still matters, and the additional L3 cache from the X3D series is a ginormous upgrade.
With the important disclaimer that this obviously is different for everyone. I play a lot of simulation/strategy games (like Cities: Skylines and Hearts of Iron) and most of the games I play actually are CPU bound, especially in later stages of the games.