Dragon's Dogma 2 is a Mess: GPU & CPU Benchmarks, Bottlenecks, & Crashes

We’ll look at all that plus some research and, ultimately, a list of CPUs benchmarked. Remember that because we were swapping CPUs and GPUs alike for various tests, we had to limit our testing to 20 total devices (counting the GPU swaps) because of the 5-activation limit.

But they got $280 out of us for this story, so go grab a GN 3D metal emblem pint glass on the GN store and pour one out for us while supporting our content. We’re trying to really expand what we’re doing with gaming analysis and that’ll directly fund it.

Dragon's Dogma 2 Research: Scaling in Game Areas

This section will go over some of our research that went into finding a test area. This is conducted by actually playing the game and taking frametime samples during the course of play. We take these manually and assign names to each sample.

Here’s the result. This was done with an overclocked i7 CPU and an RTX 4090 at 4K. In every single game we test except Baldur’s Gate, 4K is enough to shift load entirely to the GPU and avoid a CPU bind. That was true in many instances for this game also, but in the city, even at 4K, it was shockingly not enough to overcome CPU limitations even with our overclock. We’ll talk about 7800X3D and 14900K results next.

Overall though, this is what we saw across about 90 minutes of gameplay:

The range in this game is huge, with a max-min result of 91 FPS. That’s massive. That range is the size of a different GPU on its own and is a huge swing across different areas of the game. In the wilderness areas, we were in the range of 120 FPS AVG to 170 FPS AVG and we were GPU-bound in these scenarios, which we’ll prove momentarily with some captured gameplay. Combat did not have a heavy impact on performance unless high counts of NPCs were involved. The towns were the heaviest, down in the 70s-80s in our Vernworth passes and in the 98 range for the smaller Melve town. The first camp was also around 98 FPS AVG. The common factor was the presence of NPCs.

Dragon's Dogma 2 Research: Initial GPU Benchmarks

After all of this work and still set on doing a GPU benchmark, we settled on the heaviest loaded area of the game as we’d prefer to represent something closer to a worst-case scenario to give people headroom. Unfortunately, at the time, we didn’t yet appreciate just how CPU-bound this scenario was.

Here’s the first round of GPU benchmark results. As soon as we observed the RTX 4090 yielded the same performance as an RTX 4070 Ti Super, we knew GPU benchmarking would be pointless -- at least it would be in this area. This, by the way, was with the 14900K at5.9GHz, which meant we had all already switched CPUs to something higher end. Even switching to a 7800X3D, which was a major time commitment to set up as a new bench, yielded the same result as the 14900K (read our review). And this was all at 4K, so we gave it as heavy a bind as we could.

In this set of tests, the 4070 Ti and 4090 (watch our review)performed the same. The 7800X3D (watch our review) didn’t change that from our 14900K (read our review) result when at 4K, but it’s not because of a GPU bind.

The 4060 dipped, but this just isn’t enough range to produce a meaningful GPU comparison benchmark without testing in a field instead of a city. We could, but it’d be a less demanding area of the game and we wanted to investigate this behavior.

After this, we moved on and decided to make this article a CPU benchmark instead. Let’s do those charts next, then we’ll come back and look at the GPU Busy, GPU Wait, CPU Busy and Wait, and some of the simulation time error problems we observed. 

Dragon's Dogma 2 CPU Results

Here’s the CPU results with an RTX 4090 (watch our review). When everything is stock, the 7800X3D leads the chart at 86 FPS AVG -- but the game still feels terrible to play at times, with clear simulation time error in the animation. This is a metric we’re working on now. We have an interview with Intel Engineer Tom Peterson talking about this more. 

The i9-14900K is at about the same level, running 83-84 FPS AVG when CPU-bound. That has the 7800X3D (watch our review) as much as 3% ahead of the 14900K. It’s not enough to matter.

The 12100F has historically been one of the best ultra-budget gaming CPUs, but it occasionally shows hard limitations. This is one of those times. The frametimes are actually a lot worse than shown here, as averaging multiple test passes is hiding the horrible stutter in the initial pass.

Here’s a table of each of the passes for the 12100F. The first pass has a 0.4 FPS 0.1% low for one of its results, which means we were stuck on the same frame for over one second. We’ll come back to look at that in a moment. We would consider the 12100F (watch our review) unplayable for Dragon’s Dogma 2.

We even tried turning down the game’s settings all the way down, but it didn’t matter as the settings were graphics-intensive.

The 5600X exhibits similar behavior: Averaged over multiple passes, it does OK. But the first time through an area brought its 0.1% lows down to about 6 FPS, indicating large frametime spikes.

Other points of interest include the 5800X3D vs. 5800X, where we see a 16.5% benefit from the 3D cache. 

The 7950X was unable to leverage its additional cores in a meaningful way in this one: There’s a point of diminishing returns, and it’s past that point. Higher frequency would be more helpful here than going to the extreme core count of a 7950X. 

Let’s move on to frametimes.

Dragon's Dogma 2 Frametimes - CPU Bound (12100F)

Here it is. This is the insanely blown-out frametime plot from our first run on the 12100F, where we first hit an area of the city that must have begun heavier background calculations to the extent that we thought the game actually crashed. This goes beyond “stutter” and just becomes straight-up freezing, to the extent that we thought the game had crashed when it happened. 

If we zoom the scale in to see the rest, we still had to raise the roof to 800ms to accommodate the two next largest spikes. For reference, at 60 FPS, one frame is about 16.7ms to present. An excursion of 8-12ms is noticeable. Here, we have excursions of about 750ms in one instance. The game freezes-up hard and arrests at times on the 12100F.

Dragon's Dogma 2 Frametimes - CPU Bound (5600X)

Even the newer and better 5600X occasionally hits these problems. In this plot, you can see we had a frametime spike nearing 270ms, with regular spikes to 60ms. In fact, every time we pivoted the camera -- which is part of our benchmark course -- we saw microstutter in animation at best, or just actual playback stutters of the entire frame at worst.

GPU Busy

Now we’re moving on to the fun part: Game capture while using GPU Busy, CPU Busy, and GPU & CPU Wait to illustrate bottlenecks. The bottleneck is a moving target in this game and shifts between the CPU or GPU depending on the area tested. This is expanded from the past GPU Busy benchmarks we did because now we have that weight metric and that's all explained in our deep dive engineering piece.

GPU vs. CPU Bottlenecks in Dragon’s Dogma 2

In the city, tested at 4K with a 4090 and 14900K, we observed CPU Busy functionally at parity with frametime, which means the GPU is waiting instructions and can’t be fully leveraged. We see this also in our GPU and CPU wait metrics, where GPU wait is often in the 4-6ms range while CPU Wait is basically 0. We are completely limited by the CPU, even at 4K and High settings. 

You can also see this in the GPU power metrics histogram, where the GPU is under its power target.

CPU Utilization is not useful in this plot but it’s here because it’s a great learning lesson for the many who rely on a single number for this measurement because if you see us talking about CPU-bound but see a 30% number and think “No, you’re not,” that is not really a useful number. Here’s why: if you were to check HWINFO or task manager, you’d see that at least 8 cores, sometimes up to 12, are 100% loaded by the game. The remainder of the cores go largely underutilized, which contributes to the total utilization percentage being lower because it’s averaging across the entire CPU and also not all load is the same as calculated in these instances so we are in fact CPU bound even though that number is not showing 100%.

Day time is similarly constrained to night time. We are close to parity on the CPU and frametime total metric, which means we are CPU-limited.

Moving to other areas of the game, upon exiting the city, the load shifts to the GPU as soon as we’re outside of bounds where it’s processing all the AI. You see framerate climb overall, which means the frametime is reducing, with now CPU and GPU busy closer to parity with frametime. It’s actually pretty balanced out here, and the further we go, the more the load shifts to an entirely GPU-bound situation. Power consumption has also climbed to more expected numbers.

In combat, load moves around and occasionally triggers a CPU bind, but generally is GPU constrained.

In this specific example, you can also see CPU load climb disproportionately to GPU load as a griffin we fought makes its way into the water. We can’t be sure if something else happened in the background, but maybe this is from pathfinding or other NPC calculations. There is another big spike in CPU load as we get a level up and the camera pans back toward a village and town.

Re-entering town confirms what we knew: The GPU is no longer fully loaded, as the CPU now can’t keep up to task it fully. The CPU is getting hammered by the AI processing for NPCs.

The takeaway is that for testing in this game, if you want to test a worst case scenario, you’d go to the city. If you want to test a CPU scenario, it’d be the city.

If we or other reviewers wanted to evaluate GPU performance in as isolated a way as possible, it’d make the most sense to do so outside of the city -- ideally in a field with a lot of grass and increased grass quality, as that had a hard impact on performance. We noticed some animation microstutter with higher grass quality. As our earlier research chart showed, it didn't really matter whether we were in combat. You just find one of the heavier outdoors areas with a lot of polygons and hopefully avoid NPCs. That becomes the GPU load.

Dragon's Dogma 2 Performance Conclusion

This game is definitely CPU heavy in any area with heavy NPC presence. That mostly includes towns, villages, and the city we visited. In the plains, wilderness, and most combat scenarios, the game eases up significantly and can increase performance by upwards of 30% to nearly 100% at times, depending on what device combination you have. This means that, for the most part, the game can remain playable and have higher framerate in situations where higher framerate is important (like combat in the wild).

We noticed that the 12100F really had problems whenever loading a new area, and we suspect it’s because at 4 cores, there simply aren’t enough threads to task everything. It drops the render thread in favor of NPC tracking, pathfinding, physics, game state, or whatever else it’s tracking. Once an area is loaded, it’s much more reliable. But loading those areas can freeze the game and put it on the verge of crashing. We’d assume other similarly limited devices would do the same.

The 5600X (watch our review) wasn’t nearly as bad, but still had occasional 250-300ms spikes in those scenarios.

The game will load 6-8 threads heavily when they’re available. We saw instances where it went heavier than that. VRAM can also be heavy, but for the most part, unless manually maxing-out some of the settings beyond the baseline high configuration, you are more likely to be CPU-bound first.

Because individual threads can be loaded so heavily, frequency starts to offer a performance uplift that can be meaningful. This might be a game where overclocking is more valuable on some older hardware.