We put Dragon’s Dogma 2 through a series of GPU Busy, GPU Wait, and CPU Busy and Wait tests

The Highlights

• Dragon’s Dogma 2 is a very CPU-heavy game whenever NPCs are nearby
• Dragon’s Dogma 2 is a nightmare for its performance
• The GPU scaling in Dragon’s Dogma 2 is almost nonexistent when in the city, but does scale in the wilderness
• Original MSRP: $69.99
• Release Date: March 21, 2024

Table of Contents

• AutoTOC

Worst Performance We’ve Seen

Dragon’s Dogma 2 has been an absolute nightmare to work on. Aside from issues with getting locked out for 24 hours after 5 component changes due to BS DRM, which prompted us buying 4 copies of this game, it also has a singular save slot that makes it difficult to benchmark -- or even just play as a normal user. We struggled to transplant save files between Steam accounts, so we played up to the benchmark location on each account after setting the initial course.

The game is also a nightmare for its performance. Fortunately for us, that gives us a great opportunity to show the freshly updated GPU Busy, GPU Wait, and CPU Busy and Wait metrics that allow us to pinpoint bottlenecks even in times of uncertainty. The GPU scaling on this game is almost 0 when in the city, and yet it does scale in the wilderness.

Editor's note: This was originally published on March 25, 2024 as a video. This content has been adapted to written format for this article and is unchanged from the original publication.

Credits

Test Lead, Editing, Writing

Steve Burke

Testing

Patrick Lathan

Mike Gaglione

Jeremy Clayton

Camera

Vitalii Makhnovets

Web Editing

Jimmy Thang

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.

The city builder is an unoptimized mess but we help you navigate its settings and highlight which GPUs are best

The Highlights

• Cities Skylines 2 is the highly anticipated followup to 2015’s critically acclaimed Cities: Skylines
• The game is terribly optimized. The RTX 4090 is struggling to maintain 40FPS on 4K/low
• The game’s first post-launch patch improved performance, particularly for lower end cards, but there’s still a lot of room for improvement
• Original MSRP: $50
• Release Date: October 24, 2023

Cities: Skylines 2 is one of the worst-optimized games we’ve ever tested. Normally, we don’t like throwing around the word “optimized” -- but this one was bad enough that the developers themselves posted multiple panicked-updates ahead of launch to tell people as much.

In the time since launch, we’ve tested about 23 GPUs at multiple graphics settings and resolutions -- although we won’t bother presenting anything beyond 1080p, because the RTX 4090 was stuck below 40FPS AVG at 4K/low.

Today’s testing was done using a pack of save games published by City Planner Plays, a YouTuber who really focuses on the gaming side of this. City Planner did a good job with some initial benchmarks, and we’re here to pick up the torch for some in-depth performance and graphics analysis. We found everything from bugged texture quality that almost seemed inverse to the settings to bad stutters. The game itself appears to be getting updates, so that’s great to see. From what we can tell, it looks like a fun game that just needs some more time to bake -- and the fact that devs can increase performance within 2 days of launch proves that.

Credits

Test Lead, Host, Writing

Steve Burke

Writing, Research

Patrick Lathan

Camera, Video Editing

Vitalii Makhnovets

Writing, Web Editing

Jimmy Thang

Cities: Skylines II Performance Patch

Testing will be focused on a mix of comparative benchmarks and on one-off feature tests for optimization purposes. The developers specified some settings that can be tuned down for performance improvements, so we did some testing on those. We also tested each setting individually for maximum impact. We also have a section dedicated to comparing the visuals of some of the graphics presets so you know what you’re trading from one to the next.

Because the patch shipped after we’d done most of our testing, we went back to add it in. That gives us relative % scaling uplift that we can use to project the maximum uplift in the original tests. Now, with the current patch, a lot of these cards are still roughly in the same spot they originally were -- another 3-5 FPS won’t change the world in many cases, but it’s enough to help with specific cards, especially cards that are on the edge of playability.

GN 2022-2023 GPU Test Bench Specs

Research & Methodology: City Size

Let’s start with researching city size. We did this testing with our standard GPU test suite. We used the City Planner Plays files for this testing, so again, a massive thank you to him for posting some real gameplay save games to make testing easier. 

As we get into testing, one of the most important aspects will be the city size. We were able to do like-for-like benchmarks at different city sizes. The weather and time of day conditions were all the same, as was the test course, so just the city developing was the change. The impact here is crazy. This was all conducted with the patch released on October 26th, which is the first performance patch.

This chart shows an RTX 4090 at 1080p/medium settings. The scaling is clean: 

At 1K population -- pretty close to a blank map -- we’re at 115FPS AVG. That’s insane as compared to our 100K population map. That’s a 62% improvement if you were to demo your city down to a population of 1,000. To have a game with a 62% range is uncommon. We rarely see more than a 10-20% swing, with occasional 30% swings for heavy combat or effects.

In this game though, the longer your city is developed, the lower the framerate will be. We’re not sure at what point it stops scaling like this, but the performance degradation did appear to slow and become asymptotic as we approached 100K. The newer patch definitely helped smooth-out the frametime pacing on this card: Overall, the 0.1% lows here are much better than in the tests we’ll show from the older game version; however, the average framerate hasn’t moved much.

The 100K map was used for our testing, as it’s a heavier workload while still representing a realistic gaming scenario.

We’ll come back to more research after the comparison charts to show some graphics and performance optimization tips for Skylines 2.

Cities Skylines 2 Updates & Benchmarks

We’ll start with the impact from updates. Colossal Order posted this:

While this does not address all issues we are aware of, we wanted to get you these improvements as soon as possible.

Colossal Order

The changelog included these notes:

• Changed LOD to be independent of rendering resolution to get more consistent performance with high resolutions
• Minor optimization with fog
• Depth of field optimizations and tweaks
• Global illumination tweaks
• Optimized stutters when buildings spawn/level up
• Optimized various stutters across all systems
• Fixed crash after upgrading wind turbine
• Fixed crash when car crashes into still hidden car with trailer
• Fixed crash with mesh loading (that happens with low settings mostly)

When the update launched, we were actually already filming our video. We decided to pause the entire project to investigate the new patch, but this was after we’d already tested about 23 GPUs in several different graphics settings, amounting to about 500 test passes. The update included some specific notes on stutters and on LOD at higher resolutions, alongside some global illumination changes.

Let’s start with the impact from the patch alone, just showing a small subset of GPUs.

Cities Skylines 2 Launch vs. Patch Performance

1080p/Low, No Dynamic Resolution

In this chart, you’re looking at the original passes versus the patched passes. At 1080p/low, the RTX 4090 posted a 5.6% performance uplift. That’s not much, and we’re not at the CPU limit yet -- that happens closer to 112FPS AVG. The RX 7800 XT posted a 4.5% improvement in average FPS. That’s good, but from the perspective of our original round of tests, not much has changed. You can approximate these differences. The RTX 4060 saw an improvement of 9.8%. That’s more meaningful than the prior two. The 3060 posted the most meaningful uplift yet, at 11%. That moves it from 30FPS AVG to 33FPS AVG.

Not game-changing, but at least it’s better.

At the lower end, the RX 6600 posted about a 15% uplift, from 25 to 29FPS AVG. The GTX 970 was unplayable with these settings originally and remains unplayable here. The uplift was massive as a percentage -- almost 18% -- but that just means it moved from 11.7 to 13.8FPS AVG (and with a standard deviation on this specific card of 0.4FPS, that’s part of it).

The trend here is that the worse the card did, the more uplift it got. There was more ground to gain. Even without a CPU bottleneck, higher-performing cards just didn’t benefit as much -- they weren’t bound in the same way.

As for frametimes, there was improvement in most of the cards. Not always, but generally speaking, it is better.

Now we’re going to run through the original performance numbers pre-patch, but keep these numbers in mind to help calibrate against the newest version. This data will still help you figure out what cards make the most sense, as most were impacted in the range of 5-10%. You won’t see more than that typically unless under 30FPS already, at which point it’s already borderline.

Cities: Skylines 2 1080p/Medium Settings

Here’s what the options look like. When using presets, medium enables dynamic resolution scale quality as automatic. For our testing, we always toggled dynamic resolution off as dynamism impacts testing and removes like-for-like comparisons. As for the rest, medium predictably sets nearly every option to “medium.” Anti-aliasing is set to low SMAA, but everything else just says “medium.” Simple enough.

Cities: Skylines 2 1080p/Medium Benchmarks

At 1080p and with the medium preset, the RX 7900 XTX sets the ceiling at about 67FPS AVG. Lows are paced better here than they were at other graphics configurations, with more consistent frametime pacing. They’re still not great, evidenced by the wide gulf between 67FPS AVG and 18FPS 0.1% lows, but that’s far better than the single-digit entries we saw in some other presets.

The 4090 is tied with the 7900 XTX here. They are indistinguishable. The cheaper RX 7900 XT trails, giving the XTX model and RTX 4090 about an 11% advantage. We also recently revisited the RX 7900 XT and found it to be a good value with its new price drops. The RTX 4080 follows that, where the 7900 XT holds a 6% lead.

Progressing through the list, the 4070 Ti ran at 46FPS AVG, where the 4080 has a 22% advantage. The 7800 XT is functionally tied with the 4070 Ti in AVG FPS. The lows are also about the same -- although we had a single pass of the 4070 Ti where its lows tanked. But as we said earlier, that seems to be almost chance as to whether such a spike occurs in a run.

The 6800 XT is about tied with the 7800 XT, which makes sense: In our review, we found the 6800 XT was often ahead of the 7800 XT at higher resolutions, but otherwise was commonly tied.

After this, the game’s recommended RTX 3080 landed at 40FPS AVG, just below the 6800 XT. The low-end of the chart is built by the RTX 4060 at 23FPS AVG -- it could be made to work better with lower settings -- and the 4060 Ti at 29FPS AVG represents a 26% jump.

Cities: Skylines 2 Stutters & Lag (Frametimes)

The first thing you need to know is that the frametimes in this game are completely crazy. This has gotten better with the first patch, but it’s still bad -- it depends on which card you use and at what settings.

In fact, here’s a look at the RX 7800 XT after the patch that helped with stutters. This is at low settings. One of these two passes had several violent stutters over 100ms, including one spike to 322ms. That’s one-third of a second that we’re staring at the same frame, so this is still a big problem. The other pass we’re showing here is more stable -- so the game can run smoothly, but it’s not reliably smooth.

The point is that 1% and 0.1% lows are not an indicator of card quality this time because the game is so variable, so they’re more an indicator of game behavior.

Cities: Skylines 2 1080p/Low Settings

We’ll next look at low settings. The preset option toggles dynamic resolution scaling quality to “constant” -- but again, we disable that for testing so we have comparable data -- and otherwise, almost every option is set to “low.” Anti-aliasing is set to FXAA, fog is enabled, and animations are set to their lowest option, which is medium.

Cities: Skylines 2 1080p/Low Results

Here are the results for 1080p/low. The top of the chart is pinned to around 83FPS AVG, with the 4090 and 7900 XTX at the front and closely trailed by the RTX 4080. This matches what we saw at medium.

If we were to draw a line at around 30FPS, then the RX 6600, and everything below it falls short and would need further settings reductions. This includes the RTX 2060, GTX 1060, and on a technicality, the RTX 3060 -- although 29.9 is effectively 30 FPS AVG, assuming you’re OK with that framerate in this game.

While these cards were more playable in the lower population cities or empty maps, they suffered greatly as the population count and city complexity increased.

Shifting focus back towards the rest of the chart: The Skylines 2 community seems to be regularly talking about Vsync. We’re confused why, because this setting isn’t anything new nor does it behave in a different way in Skylines. It is completely normal behavior. We ran it on a 4090 just to reiterate an ancient point: Vsync will cap to the screen refresh rate, so on a 60Hz display, that’ll be a 60FPS maximum value. That’s exactly what we got. Doing this can help eliminate frame tearing, but will introduce potential stutter problems in scenarios where frames are not ready on the flip interval. Nothing new there, though. In this scenario, the 4090 is sufficiently fast against a 60Hz refresh, leaving it able to more evenly pace frames and be less constrained overall.

The RTX 3080 ran at 61FPS AVG here. That’s the card the developers recommend. The GTX 970 was its minimum, which struggled hard: Even at 1080p/low, we could barely exceed 11FPS AVG. Turning depth of field completely off and setting depth of field Quality to off -- just for good measure -- we saw an increase of 9% to 12.8FPS AVG. That doesn’t really help. We’ll revisit this card at very low.

The 7000 series RX GPUs seem more advantaged here than we’ve seen in some other games. The RX 6800 XT generally outperforms or more closely equates the RX 7800 XT, largely because of its CU count advantage, but we’re seeing the 7800 XT pull ahead in these charts. The same goes for the 6950 XT and the 7900 XT, where we’d normally see them closer together or sometimes flipped.

Cities: Skylines 2 1080p/Very Low Settings

“Very low” configures almost everything to a simple state of being toggled off. Anti-aliasing is disabled, terrain quality is set to low, water quality is set to low, LOD is also low, and animations are medium.

Cities: Skylines 2 1080p/Very Low Benchmarks

First off, we’re becoming bound at about 110FPS AVG. Everything from 104FPS to 112FPS is at least occasionally hitting other limitations, which means we aren’t seeing the true GPU performance here. You cannot declare any one of these is better than the other based on these numbers. We’re bottlenecked. Of course, realistically, a framerate this high in Skylines just means you should increase the quality, at which point you see them diverge as shown in our earlier charts.

Let’s start with the GTX 970. With every single setting toggled to its lowest configuration, except depth of field at Physical, we’re seeing a result of 28FPS AVG. Maximally, a DOF toggle would gain you 2-3 FPS here, for a possible throughput of about 30FPS AVG. The lows are bad, though: You’re going to encounter stuttering frequently, and in particular, rapid zooms or camera movements will provoke them. On a technicality, this card is playable. You might want to reduce resolution though.

Because this game seems best played at 1080p, the RTX 3060 Ti is actually beaten by the RTX 4060 Ti. You might recall that memory bandwidth limitations on the RTX 4060 Ti were severely hampering it generationally, which often results in regressive performance against the 3060 Ti when resolution is increased. We found that the 4060 Ti almost universally lost to the 3060 Ti at 4K. At 1080p though, it’s ahead.

The GTX 1080 Ti is sticking around too, holding 72FPS AVG at the lowest preset. AMD’s newer RX 7600 is roughly tied with the 1080 Ti. You’d be able to increase settings quality on these cards. The 3060 is positioned similarly, as is the 2070. As for the 4060 non-Ti, that leads the closely competing RX 7600 by about 10%.

The biggest thing we saw here though was better frametime pacing. Although not great overall, most of these cards are at least in the 30s for 0.1% lows. The RTX 2060, GTX 1060, and GTX 970 all had highly variable lows. Remember again that these don’t necessarily tell us which card is better than the next if it’s highly variable: Although that is true higher up the stack, these weaker cards struggle. What it really tells us is that they’re struggling with consistency in this game, and that’s due to the heavy workload.

Cities Skylines 2 Graphics Settings Explained & Compared

Image Quality Comparison: Very Low vs. Low

Cities: Skylines 2 Optimization Research

Our next chart looks at individual graphics settings. For purposes of this test, we only had one objective: Pick a card at about 30FPS AVG when at baseline 1080p/low, then tune the settings down individually to identify what helps the most. The reason we chose “low” as a baseline is because the gap between low and very low is gigantic. On the GTX 1080 Ti, that meant moving from 32FPS AVG to 72FPS AVG. That is MASSIVE. We normally see swings closer to 10% in games between settings -- Starfield was almost perfectly 10FPS per preset. In this game though, the gulf between very low and low is wide enough that you could shove a 4090 through it. That means there’s a lot of room to make the game look better for players who can’t play low, but have framerate that’s excessive on very low.

We didn’t do this for every card. If we did, it’d have been 322 combinations just to test low against very low and off individually. But this does appear to be largely scalable as a percentage, so even with one case study on the GTX 1080 Ti, you’ll have enough to apply that knowledge to your own GPU.

Cities: Skylines 2 Settings Optimization

Baseline low with dynamic resolution off is at the top. Toggling depth of field completely gave us a 33.6 FPS AVG for both variations. The first was toggling it from baseline Physical to off, the second entry in the list was also toggling the quality to off (which presumably should do nothing when the setting is off altogether). That’s an improvement of 5.7%. On the 970 earlier, we saw closer to 10% -- but the framerate was also much lower, so the impact may have been disproportionate.

Each entry only changes the setting listed, so DOF remains on Physical for the rest. That means you compare each line item against the top “low” entry, but not the prior entry.

Turning off volumetric effects got us to 35.2, a boost of about 11%. That’s significant and could be a place to find a lot of extra performance. We also did a test with the Colossal Order recommended settings, so depth of field off, volumetric off, and motion blur off. There was functionally no impact as compared to the prior tests. Volumetric alone achieved similar results. The gains didn’t stack here -- or not by much. We did get a stacking effect materializing in the frametime pacing, though: You’ll notice that improved markedly.

The two biggest impacts came from level of detail and shadow quality. That’s normal in a game: shadow quality jaunted us in huge ways, gaining us 37% performance. Level of detail scaling, at least for the launch-day patch, boosted us 29%. As for ambient occlusion, clouds, anti-aliasing (from FXAA baseline), and texture quality (on a card with sufficient VRAM), none of those really affected things much. You could leave these at low or boost them higher to increase fidelity without much loss of framerate. Fog boosts framerate when disabled, and since some people seem to really hate how the setting looks anyway, that’s potentially a win-win. Reflections didn’t do much in our test environment, but might have more impact in other specific scenarios. Global Illumination was alongside volumetric as having moderate gains.

Cities: Skylines 2 Updated Settings Research

Time to look at how the first patch affected the game. We re-ran a few of our tests to quickly check on if the scaling we saw in the last chart changed.

We re-ran tests for the baseline low result, depth of field, and global illumination. We had to limit the time re-investment since we’re already 3 days into this piece, and these are some of the specific settings that were named in the update without getting into resolution scaling from LOD.

The low baseline improved to 35.6 from 31.8, or an uplift of about 12% in this configuration. The original depth of field toggle was a 33.6 FPS AVG, an uplift of 5.7% on this card. The patch boosted that to 36.6 FPS AVG, so we’re only seeing a 3% uplift now. You can’t compare the unpatched low baseline to the patched depth of field toggle. That wouldn’t be relevant. The improvement is less significant now than it was before, which suggests changes to depth of field at baseline.

The global illumination toggle previously improved performance to 35.5 FPS AVG, an uplift of 12% against the original baseline. The new result is 38.2, an uplift of 7.3% against baseline. The reduced improvement again aligns with the patch’s changes to global illumination. This game is still performing poorly overall, but the patch brought a huge improvement. They really should’ve had the two extra days to push this prior to launch.

Cities: Skylines 2 Shadow Quality Comparison

Because shadow quality had some of the biggest impact on performance, we’ll spend some time showing a side-by-side of the setting. This is only comparing the low option versus the toggled off option.

When shadows are toggled off, you’ll notice the three-quarters angle of the city lacks any shadowing at all on the trees in the lower left corner. The park centrally also shows this well, where we have a very flat-looking image. They should just call this option “Sim City 3000.”

Looking at the buildings in the city, we can also see a removal of shadows along the inside walls of the buildings. Toggling it on and off a few times, you can really see the impact of even just going to low shadow quality. But remember, on our 1080 Ti case study from baseline low, the cost was 37%. 

Zooming-in to the city makes this really apparent. The absence of shadows is clear here, so we probably don’t need to point-out the individual examples. The car undersides make it particularly obvious, but even the curb has shadowing when this close to the street.

It’s also clear in the trees in the background, where toggling shadows off removes any depth or self-shading from the leaves and canopies.

If you’re desperate for performance, you should turn this option off. But unlike settings where there’s sometimes no visual improvement for a high performance cost, this one does have a visual change that’s tied to the performance impact. 

Cities: Skylines 2 Preset Comparison   

Comparing the presets now, we're going to split our benchmark course into a few scenes and cover them in order. Keep in mind that changing the presets changes every setting simultaneously, so in this section, we can't definitively say that any one change we notice corresponds to one setting. Note that resolution scaling was intentionally disabled for these tests, although it would normally be a part of each preset.

Starting with a wide shot of the city, the first visible difference is the lack of fog at the very low preset. Fog quality is simply marked "enabled" at every other preset, and it doesn't change in appearance between them, but at very low, the full-screen haze is completely gone. Frustratingly, the fog gets in the way of most of the other settings we want to compare.

Graphics Quality Preset Comparison: Very Low vs. Low, Medium, High

This should help us determine if it's worth using higher presets. The next most obvious change is shadows again, with very low automatically setting shadow quality to "disabled." We won't waste time rehashing that: no shadows means no shadows. At this distance, though, even the differences between quality levels with shadows enabled is unclear. Neither the draw distance nor softness of the shadows changes visibly. We'll check back on that once we zoom in.

Interestingly, there's a clear increase in the quantity of distant trees when moving from the very low to the low presets, but no change above that. Out of the given settings, we'd suspect that trees are governed by LOD or maybe terrain quality, but each of these settings is supposed to scale up with presets above low.

The highlighted power lines between the pylons crossing the river pop in sooner at medium and high, but we haven't played much Skylines and it's unclear to us whether these highlights are even intentional. 

With a ton of qualifiers (in this relatively flat city, on a sunny day, without any water-related disasters, at this distance, at this resolution), we haven't seen a meaningful difference between low and high presets so far. Let's keep looking.

Continuing to pan around the city, there are clearly visible reflections of bridges, roads, and boats on the surface of the river at the medium and high presets, but not below that. Reflections move from disabled with the very low preset to low at the low preset, but evidently the lowest tier of reflection quality doesn't include these elements.

There are definite changes related to anti-aliasing between the presets, but not always in the expected direction. Moving from zero AA to FXAA by bumping the preset from very low to low dims some of the sparks along the edges of roads and bridge wires, but the fog is also a factor. The shimmering actually increases on the sides of high-rise buildings in combination with increased LOD, and becomes even more prominent at the medium and high presets. As we zoom closer, the buildings become almost grainy with detail at those higher presets.

Zooming into a single street, we can begin to see more subtle differences between the presets. The shadow under this tree next to the sidewalk is slightly sharper at the medium and high presets than it is at low. 

In addition, the dithered edge of the shadow of the brick building at the right of the above image becomes sharper as well. 

Specifically at high, the small yellow car parked along the street here casts shadows down from their side mirrors, but that's because the LOD setting erases their side mirrors at this distance. 

Also, the handlebars on the red motorcycle below are completely erased (likely by AA) at the two highest presets.

Zooming along streets, motion blur is nonexistent with the very low preset, but increases in intensity from low to high. In addition to the intentional scaling of blur quality, lower FPS at higher presets is a potential factor here: the developer specifically warns that "Motion blur can be very visually disruptive if you have low FPS."

Moving to the very end of our course, scaling in reflection quality is visible in the cars lining the street. At medium and high, the cars lining the street clearly reflect their own side mirrors, while progressively more detail is added to the reflections on the side of this red car.

Bizarrely, the quality of the textures on the signs at the end of the street get progressively worse with each step up in preset quality. At very low, the green-and-yellow billboard is crisp and readable, but at high, it's no longer recognizable as a billboard at all. Other nearby textures suffer the same effect, like the benches and the leaves on the trees. We also saw this in the street textures when up close, the back of cars, and other objects. This seems either completely broken -- as in, they flipped the settings -- or seems to be an issue with rendering due to load intensity elsewhere. This was captured on an RTX 4090, so VRAM is not a limiting factor.

Overall, isolating our analysis to this specific benchmark course, we don't see any compelling reason to pick a preset above medium. Other than some reflections, even low doesn't look much worse than high in this area. Again, we disabled resolution scaling for these comparisons, so we're not taking that into account. It uses an FSR 1.0 implementation, so you get a lot of flickering and polka-dot patterns as they pop in and out.

Conclusion

First off, we need to address something that we saw in a few reddit posts online: Some people were claiming that disabling depth of field boosted them from 22 FPS to 122 FPS. We saw a Steam review that also claimed multiples of uplift.

That isn’t true. That’s not happening. Depth of field will not provide that much uplift. We noticed that Skylines has issues with applying resolution and we had a few bugs where it’d shift to a higher resolution than initially specified. We think the more likely scenario is that someone reset the resolution without realizing it. Something else is changing, because we could not replicate those numbers in any scenario.

As for performance impact: There’s a huge swing from very low to low. The developers have bad defaults here -- they should have more even spacing, or add another named setting between these, to give players a better balance without making the game look like trash. An example might be "Ultra Low" to drop-in below very low, then low above that. That'd give them some room to close that 2x gap between very low and low, allowing players to balance visuals better with the performance cost.

Older cards have the most trouble here, but to get some performance out of them, try bumping shadows down and tuning volumetric effects. Check the settings guide section for more advice on which options to tweak. 

Best GPU for Cities: Skylines 2

If it wasn't already made clear, Cities: Skylines 2 is currently a mess, but if you’re keen to play it right now, we’ll give you our GPU recommendations across two framerate targets (30FPS and 60FPS). 60FPS is obviously preferable for most of our audience, but considering how poorly optimized the game is, that target may prove a bit too financially costly to some. In addition, seeing as how Cities: Skyline 2 isn’t some fast-paced shooter that requires pin-point precision accuracy, 30FPS becomes a more tolerable framerate here.

Speaking of target, we’re going to base our recommendations on 1080p/low and 1080p/medium. While the very low setting does show a big uplift in performance, the resulting visual downgrade isn’t worth it in our opinion. Furthermore, the visual uplift from medium to high isn't significant enough to justify its bump in performance cost.

The two GPUs that make it over the 30FPS average hump at low include the GTX 1080 Ti and the RTX 2070, which got 32 and 31.7, respectively. Owners of these cards skate by. If you’re looking for something newer to purchase, the RTX 4060 and RX 7600 would be our picks. They got 34.4 and 37.4 average FPS, respectively. The AMD RX 7600 offers a better value at $260 since it’s cheaper by roughly $35, but the 4060 can hold its own in other games -- ones not named Cities: Skyline 2. Broadly speaking, the RX 7600 provides a better value here.

If 60FPS is what you seek, we recommend the RX 6800 XT. AMD’s GPU garnered 63.7 average FPS. In terms of current street price, it'll run you about $480. It's technically last gen, but it's often better than the 7800 XT.

Both the RX 6800 XT and RTX 3080 (and likewise, the modern 4070) are also respectable cards that can handle the game at 1080p medium, garnering 45.4 and 39.9 average FPS, respectively. The RX 7700 XT is a more affordable option here. It garnered 39.2 average FPS. That card carries a street price of $440. If you're aiming to game at 60FPS on medium, we would recommend stepping up to the RX 7900 XT. Our PowerColor Hellhound variant garnered 60.2 average FPS. It currently retails for $800.

Baldur's Gate 3 rolls with advantage to earn a place in our benchmark suites.

The Highlights

• BG3 proves lightweight on GPU, but holds more potential for CPU testing
• Intel Arc GPUs struggle in DirectX 11 mode
• GPUs from several generations ago can still reach playable framerates
• Original MSRP: $60
• Release Date: August 3, 2023

Table of Contents

• AutoTOC

Intro

We're running a simple benchmark today for Baldur’s Gate 3; it's going be a lot of fun. We tested over 30 GPUs for this one, mostly because it's not that GPU intensive, so we had to scale back to older stuff to see how that did. This has been a wildly popular game, and for good reason. After all of our Starfield coverage, we thought we really should go back and visit Baldur's Gate 3 since we kind of missed it when it first dropped, and now is a good time to take a look at it. The game deserves it and has been held in high regard.

So again, because Baldur's Gate 3 is so lightweight on the GPU in general, we took it as an opportunity to explore a couple of things: One was testing some older cards and some eclectic ones like Vega 56, and the other really cool opportunity was exploring "GPU Busy" some more. GPU Busy is a new test metric that we've been working to bring to the forefront of hardware reviews, as we see its future expansion options to be a huge opportunity to provide insight as to where hardware gets bound-up in performance.

Credits

Host, Writing, Testing & Lead

Steve Burke

Testing

Mike Gaglione

Testing, Web Editing

Jeremy Clayton

Camera, Video Editing

Vitalii Makhnovets

Video Editing

Tim Phetdara

Watch Video

GPU Busy Recap

We talked about GPU Busy as a new metric for performance reviews in an interview with Tom Peterson previously and we first used it in our Starfield coverage. It's really interesting; it's only the start for what this can do eventually in terms of unlocking deeper insights. This particular game is an interesting one to use for GPU busy because of the lightweight tasking of the GPU, plus some unique issues with DX11 on Intel Arc. Let's get started.

Other than the 30 or so cards at the three different resolutions, we are also using this to test-drive GPU Busy. The quick recap is it's a new insight that’s granted through an open-source logging utility called PresentMon. It's been around for a long time and is commonly used to log frametime performance in games. Frametimes are the base metric of FPS, which is a rate. FPS is an abstraction away from the base metric, which is time. In other words, it’s a measure of how long the frame takes to generate and appear on the screen. You can do a simple calculation and convert that into FPS, but originally it's just time.

• PresentMon overlay (not used in testing).

GPU Busy effectively looks at the amount of time spent in each frame by the GPU doing meaningful work. So the closer the GPU busy number is in frametime to the actual total composite frametime number, the more GPU utilization you’ll have. If they are distant from each other, for example, if GPU busy is down at 1 millisecond but the frametime is 7 milliseconds, you've got 6ms +/- where the GPU isn't really doing anything. In that case, maybe you're CPU-bound, maybe you're memory-bound, or there's a game, driver, or framerate cap, or something like that. It's only the beginning for GPU Busy. The hope is that this will expand to allow us to see CPU Busy or maybe memory or cache back pressure on the GPU if we're running out of memory on the card. Maybe these metrics will one day be able to tell us that. It's just a matter of if it gets turned on eventually.

With that out of the way, BG3 is a cool excuse to explore GPU Busy in this benchmarking. Let's just get right into it. We're going to start with our research section. Research is when we try to understand how the game performs and we pick a benchmarking location that stands as sort of a heavier case scenario but not the worst-case scenario.

Researching Baldur's Gate 3's Performance

We are currently in the process of overhauling our GPU and CPU test benches with newer games. Baldur's Gate was on the list for things we might phase-in to replace other stuff. The question was whether it should be in our CPU test suite, GPU test suite, or both. It appears like it might go in both, but we might only utilize it for GPUs when they're below something like an RTX 4080 or RX 7900 XT class of card. The game appears to be potentially very CPU heavy, or at least it becomes GPU-bound early at 1080p on a high-end card. So, it will probably end up in our CPU suite. It's also going into our handheld gaming suite because it's lightweight enough that you can play this on decent APUs these days or IGPs. It’ll pop up in our next handheld device gaming review, which should be coming up soon.

• Yes, we got the sword.
• Big thanks to GN Patreon Discord member 1nfinityzer0 for providing late-game save files.

Our research process for a new game is actually really fun. It involves playtesting in various locations and getting to know the game as a player. We made our own character for early game testing, and then we acquired a save game file from a viewer whose character goes by “Hawke” for later game testing. Thank you to our Patreon Discord member for sending us that.

We tested in combat, in the forest, zooming in closer to characters, zooming all the way out. We tested conversations, and we tested in Baldur's Gate itself. The research took place on an RTX 4060 at 1440p Ultra, and we chose this card and these settings because we wanted something that was definitely GPU constrained but not so constrained that the data wouldn't really be differentiated.

Research Results

All of these various scenes all averaged together are 69.5 FPS, with lows behind but steady at 42 and 34. Baldur’s Gate city seemed to hover in the 60s, although we encountered one conversation with a troll – and not the kind we see in the comments every day – where our frame rate dropped to 56 FPS AVG. The other conversation was at about 60. These higher-quality assets that load in during conversations impact framerate. It looks nicer during those scenes, but it’s not a constant part of the game.

The crowded market still ran at about 67 FPS AVG. As for the game start area, including the Mindflayer scene, we were in the same range as the city – maybe a little higher. Testing in the hollow, we were around 81-75 FPS AVG. This is a significant jump and appeared to be outside of the average thus far, so it wouldn’t make the most representative test bench site and we decided not to use it for testing.

Wilderness combat had us in the 70s, also higher than Baldur’s Gate itself. Zooming-in in the wilderness dropped our framerate by over 10FPS, something we couldn’t replicate in Baldur’s Gate city. It was much more consistent there. We think this is just related to the proximity of other character models to the camera, plus the wilderness zoom had a longer sightline before occlusion might have culled assets.

Our bench course was about 65FPS AVG. This was in Baldur’s Gate, where we ran down a long sightline during the earthquakes. With research done, we can look at the comparative data next.

Baldur’s Gate 3 GPU Benchmarks

GPU Test Bench (2023)

4K Ultra Benchmarks

Tested at 4K/Ultra first, the RTX 4090, RTX 4080, and RX 7900 XTX establish our CPU ceiling: Even at Ultra and 4K, this game just isn’t loading these GPUs completely. They can’t distinguish themselves from each other. Our takeaway here is that we may introduce this game to our CPU review suite in the near future, because this could prove to be an excellent and modern CPU benchmark title. It’s good for GPUs, but for anything that’s more than about $500 and was released anytime recently, it may not be enough load.

The RTX 4070 Ti is the first that meaningfully falls below our ceiling, so that’ll act as the first uncapped result. Let’s start with the most recent cards:

The RX 7800 XT’s 63 FPS AVG has it about tied with the RTX 4070, although behind in 1% lows. This is a good position for the 7800 XT considering the 4070’s pricing. The 6800 XT, as we saw in our 7800 XT review, manages to outperform the newer card by 7.6%. It’s still proving the better value between the two. As for the 7700 XT, that one leads the 3070 FE marginally, again with lower 1% lows, and leads the 6700 XT by 23%.

Most cards from the last few years can run this game above 40FPS even at higher resolutions. We have even more cards tested at lower resolutions.

Intel had significant issues with DX11 in this game. If you’re using Arc, we’d recommend you switch from DX11 to Vulkan. We didn’t see meaningful change on NVIDIA or AMD in most cases, but with Intel, it’s a gameplay-breaking difference. If you have Arc and you’re playing this game, you really need to switch to Vulkan. The A770 LE with DX11 suffered in lows, and even the average improves 13% with the Vulkan result.

Intel Arc DX11 vs. Vulkan Frametimes

Let’s look at a frametime chart for Arc briefly.

In this frametime plot, drawing the DX11 line for the A770 first, we see frequent spikes to 80-120ms. This is similar to what we saw on Arc back when it launched for some games. Intel was able to rectify this behavior in games like CSGO previously and has been re-architecting its DX11 drivers recently, so there’s a chance this can go away. For now though, it’s a very stuttery experience with messy frame pacing. The experience is objectively bad: There are long and noticeable stutters that materialize with DX11 for Arc.

Adding the line for Vulkan, things smooth out. It looks flatter than reality due to our scale, but the Vulkan performance is aligned with what we’d typically see for frametime pacing. It’s much better. There are still some spikes to around 80ms, so that’s not great, but we’re reduced to about 5 of them instead of multiples of that.

GPU Busy - Intel Arc DX11

GPU Busy is an interesting metric here. This chart shows the DX11 frametime plotted against the GPU Busy time for Intel Arc. We’ve zoomed it in, so it’s truncated the scale. You can see that despite the frames sometimes taking 120ms to complete the frame, the GPU busy time is often around 30ms. That tells us that, for 30ms out of 120ms, the GPU is the busy part. We also know we’re not CPU-bound, and so we’re left with a few possible assumptions. Our strongest one is that it might be that we’re getting sent to system memory due to a GPU VRAM utilization issue, likely caused by drivers.

1440p Ultra Benchmarks

Moving to 1440p/Ultra, the ceiling remains about 90-95FPS peak, or anything in the 80-90FPS range for averages. We can ignore those cards at the very top – just know that an RX 7700 XT or 3070 and up are encountering our CPU bind at 1440p/Ultra. The game isn’t that heavy. We’re planning to update the GPU benches soon, but that’ll come with the Intel 14th Gen.

Even the RTX 3060 Ti manages 80FPS AVG here, which is more than high enough for a game like Baldur’s Gate. Turning our attention to lower-end cards, the floor seems to be about the GTX 1070 (for what we tested) if your target is 40 FPS or better. By modern standards, that’s a low floor. Any upper-mid-range or high-end card released in the last 8 years or so should have no trouble playing this game at a good framerate even at 1440p/Ultra.

For relative scaling, Arc still struggles compared to cheaper alternatives. The RX 7600 – around $250 these days – is outperforming the A750 on Vulkan slightly while having generally more reliable drivers overall. NVIDIA’s 4060 offers 2.5% more performance than the RX 7600, so in this game, it’s not strong enough to justify its cost. You’d find that maybe in other games, but not here.

Let’s move to the big chart.

1080p Ultra Benchmarks

Now we’re on to 1080p/Ultra, where we’ll have a lot of older or lower-end cards. To point-out a couple of eclectic offerings, we have Vega 56, the RX 580, the A380, and the GTX 1060. We could have gone even lower-end, and looking at the data now, this game should even be playable on modern IGPs. This game is very scalable on most cards.

At these settings, the Intel Arc cards hold a good average (compared to previously) and much more agreeable lows. They’re still disadvantaged against their peers here, but are playable. Comparatively though, the value just isn’t good: The RX 6600 equals the more expensive A770 while holding better frametime consistency. The GTX 1060 remains relevant here as well, with a 41FPS baseline – that’s fine for this game. It’s not like it’s an FPS. Lowering settings would boost it more.

The RX 580 is also borderline, depending on how picky you are. You could drop settings and get into the 40s while staying at 1080p, but it’s doing okay. Intel’s A380 struggled and we wouldn’t recommend it for this game, but could be made to work.

1080p Medium Benchmarks

We ran the RX 580 and Arc A380 at Medium as well. There’s not much on this chart since the game is so widely playable – you could play it on modern IGPs and APUs without much trouble. The A380 on Vulkan and RX 580 hover around 37-42FPS AVG at medium.

Conclusion

Wrapping this up, this game is easily playable on just about any discrete GPU that's been made in the mid-range or especially high-end tier in the last five years. Going back about eight years, if the card was on the higher end originally, like say a GTX 1070, it still can play this game. Especially because Baldur's Gate doesn't need something like 60 FPS. It's a turn-based game for the most part, and even with some occasional stuttering, it's playable at lower frame rates. This one, in particular, seems like a lot of people would probably be just fine at 40 FPS or something. You don't need to shoot for those FPS gaming numbers.

GPU Recommendations for Baldur's Gate 3

Based on our numbers and assuming you're buying a new GPU in part for this game, our recommendations are largely centered around more affordable cards. An RTX 4090, RTX 4080, RX 7900 XT, or similar card would be overkill for Baldur's Gate 3. It wouldn't get utilized. The best GPUs for Baldur's Gate 3 tend to be more affordable, where "best" means maximum performance for a good value. If your main game is this one, we'd strongly recommend these:

1080p/Ultra

For 1080p gaming, the workload is relatively lightweight in BG3. You'd have more than high enough framerate with the below cards (ignoring cards that were high enough performance to bottleneck on the CPU):

• ASRock RX 6600 on Newegg or the XFX RX 6600 210 on Amazon
• MSI GTX 1660 Super on Newegg or you can find an MSI GTX 1660 Super Ventus on Amazon
• If you're willing to deal with some driver issues in games, Intel's Arc A750 (with Vulkan) is worth considering these days -- but we'd only recommend it for enthusiasts who are patient

1440p/Ultra

At 1440p, the load is a little higher due to the resolution increase. If you want to maintain a relatively high (50+) framerate for Baldur's Gate 3, based on our testing above, we'd recommend these cards in order of performance:

• ASUS RTX 4060 Dual on Newegg or you can find a similar RTX 4060 card on Amazon
• XFX RX 7600 Black on Newegg or PowerColor RX 7600 Fighter on Amazon
• MSI RX 6600 XT on Newegg
• Zotac RTX 3060 on Newegg
• Intel Arc A770 on Newegg (again, if willing to deal with driver issues in games and if using Vulkan in this one -- enthusiasts only)

4K/Ultra

Finally, for 4K, the following cards were effective without going completely overboard:

• While still available, the last-gen RX 6800 XT (Newegg) remains one of the best values right now. The RX 6800 XT often outperforms the RX 7800 XT in our testing, especially at higher resolutions, thanks to higher CU count. See our review for details.
• Otherwise, the RX 7800 XT (Newegg) is an OK alternative if you can't find the 6800 XT. You can also find the RX 7800 XT on Amazon.
• On the NVIDIA side, consider this Zotac RTX 4070 (Newegg) or MSI RTX 4070 (Amazon) primarily if you have other uses for it: Maybe you want Ray Reconstruction in Cyberpunk or similar features.
• For something generally cheaper, the RX 7700 XT (Newegg) is also an OK consideration -- although we suspect we'll be recommending it with more emphasis once AMD drops prices.

Performance Recap

For performance, based on what we're seeing here, modern IGPs really should be no problem with this. Subjectively speaking, the graphics are not particularly mind-blowing, but they seem pretty good for the type of game that this is, for the focus it has, and for what it's trying to do. It runs extremely well. Because of that, it means that this is a very accessible game on a lot of different platforms and a lot of different hardware. That's probably a sigh of relief for a lot of people who've seen how the Starfield launch went over.

At the very least, this gives us some hope that not every game is going to heavily lean on upscaling technology in the future to try and make up for performance deficits elsewhere. FSR is in the game, but we didn't even turn it on because it's too performant already. It's already difficult to tell high-end cards apart at 4K.

It was fun for us to work on this one. Hopefully, for those of you who are on older hardware, this is helpful to you so you can figure out what might make sense to upgrade to if this is your primary game. You can see there's diminishing returns at around the $600-$700 price class for this title. If you're only really going to play this, you don't need to buy up to an RTX 4080 or an RX 7900 XT. That said, the RX 7900 XT has been a particularly good value lately (if you play more demanding games), with the new-ish 7900 XT Hellhound leading the way for affordable variants of this card. We've benchmarked this card fully and found it to perform well overall -- a review is coming up soon for it. But it's not needed for BG3. You can go much cheaper than that and get basically all the performance you'll ever want for Baldur's Gate 3.

We had fun with this. It's nice to do shorter or simpler benchmarks sometimes. Enjoy Faerun!

Cyberpunk 2077's free 2.0 update leverages a new DLSS 3.5 feature: Ray Reconstruction & Phantom Liberty

The Highlights

• NVIDIA AI model replaces hand-tuned denoisers
• Returning to the era of brand-exclusive graphics
• DLSS really can be "better than native" (sometimes)
• Release Date: September 21, 2023

Table of Contents

• Intro
• Explaining NVIDIA's New Ray Reconstruction Feature (& DLSS 3.5)
• Cyberpunk 2.0 RT/DLSS Feature Compatibility
• Visual Comparisons
• Cyberpunk Ray Reconstruction Benchmark Performance
• Conclusion

NVIDIA and CD Projekt Red really want everyone to know about the new Cyberpunk updates and DLSS 3.5; in fact, they want people to know about it so much that they had at least 4 different embargoes.

It’s like a way worse version of an unboxing embargo. The first was a coverage embargo to tell everyone that there are embargoes, the second was for reviews of Phantom Liberty, but only using screenshots and B-roll from CDPR, or self-captured screenshots—which could just be captured at 60FPS and combined, but whatever. They then had one for today, which is Cyberpunk 2.0, where we can provide something useful rather than pure marketing using first-party materials, then there’s another for Phantom Liberty later. We are able to use our own materials for this particular embargo lift, and we're going to be talking about the real technology behind all this.

What interests us here is “ray reconstruction.” This is a new feature that debuted with NVIDIA's DLSS 3.5: Cyberpunk 2.0 is a combination of all of the updates to date. If you haven't played Cyberpunk since launch and were waiting for a time to jump back in, this is the time to reevaluate, as 2.0 is a major change and Phantom Liberty is coming up.

Credits

Host, Writing

Steve Burke

Testing, Writing, Research, Web Editing

Patrick Lathan

Writing, Research

Jeremy Clayton

Video Production

Vitalii Makhnovets

Explaining NVIDIA's New Ray Reconstruction Feature (& DLSS 3.5)

For our part, we're going to talk about how ray reconstruction works and what it is at a base level. We'll have some visual comparisons with it on versus off and some light benchmarks (lightweight, not just literally light). Ray reconstruction has a big influence in certain areas of the game on how the light looks when you interact with the environment and light sources.

This piece focuses primarily on the ray reconstruction aspect of DLSS. DLSS is an existing technology and we've looked at it a couple of times now, for example in our Cyberpunk piece with RT Overdrive, and more recently in Starfield when we modded the game to add frame generation. If you're interested in DLSS or specifically frame generation, you should check those pieces.

Ray Reconstruction Defined

We'll start with an explainer: "DLSS 3.5" essentially means ray reconstruction. NVIDIA has a helpful table (above) for the different versions of DLSS and what cards they're supported on. For example, frame generation is supported on the RTX 40 series, all the way down to the RTX 4060, while ray reconstruction works on all RTX cards, including the RTX 3080 and older RTX 20-series GPUs.

Ray traced lighting works by casting rays from the camera, letting them bounce around to find light sources, and then working backwards to see what light should return to the viewer. We've covered that topic before; watch our interview with Intel's Tom Petersen back when he was NVIDIA's Tom Petersen for more detail. Working backwards simplifies the process, since it means only dealing with light that actually reaches the camera within a finite number of bounces. Still, that's a ton of computation to do in real-time.

Therefore, only a few rays are cast per pixel per frame in games: for example, Portal RTX casts ~25 rays per pixel with a maximum of 8 bounces, according to NVIDIA. As the rays scatter over the scene, the result is an inconsistent dusting of individual samples of light returned to the camera.

The gaps are filled in with denoisers, averaging data both spatially (between pixels in a single frame) and temporally (with pixels from past frames). If the denoising doesn't work well, either through a lack of samples or tuning, it can lead to sparkling, shimmering, or "boiling" effects. According to NVIDIA, denoisers are currently "manually-tuned and processed for each type of ray-traced lighting present in a scene."

NVIDIA is in an interesting position here, where it suddenly has to point out all the flaws and failings of RT denoising in Cyberpunk 2077, its flagship game for DLSS and RT, in order to highlight the advantages of its new technology. The main examples that NVIDIA directly provided were ghosting, as lighting data is incorrectly retained from previous frames, and lower quality RT effects, as a lack of data leads to detailed shadows and reflections getting smudged out. These shortcomings apply to other RT games as well, depending on how the denoisers are tuned.

This is where ray reconstruction comes in. This is theoretically a no-downsides upgrade that fully replaces existing denoisers with "an NVIDIA supercomputer-trained AI network." If that sounds like an extension of DLSS upscaling, that's because it is: NVIDIA told us that "Ray Reconstruction is a combined AI model with Super Resolution." Taking ray samples and motion vectors as input, it intelligently predicts and outputs fully-lit frames as opposed to applying a blanket algorithm. According to NVIDIA, the model is being trained to "be able to handle all types of content" and doesn't require a return to game-specific training, although we at GN can only speak to Cyberpunk 2077 so far.

Cyberpunk 2.0 RT/DLSS Feature Compatibility

Here's the breakdown for Cyberpunk 2077: Ray Tracing can be enabled independently on any brand of RT-capable cards, no DLSS required. The same goes for path tracing, which is a more complete implementation of RT (watch our video). Frame generation can be enabled independently on NVIDIA 40-series cards, no DLSS upscaling required, even though it's a "DLSS" feature. Framegen also makes NVIDIA Reflex mandatory (in Cyberpunk), but we're not getting into that today. Ray reconstruction can be enabled on RT-capable NVIDIA cards only if DLSS upscaling is used and path tracing is enabled. We asked about the upscaling requirement, and NVIDIA stated that "we plan to add support for native resolution using DLAA." For now though, NVIDIA has finally created a scenario where (on paper) DLSS is better than native.

Visual Comparisons

Let's take a look at what ray reconstruction actually does in game. All of these scenes were captured at 4K using an ASUS RTX 4090 and an i9-13900K. For our baseline settings, ray reconstruction was enabled and DLSS was set to Quality.

One problem: NVIDIA's review guide recommended DLSS Auto, which is completely insane, and we hope nobody took that advice. It introduces a huge variable. We did not follow this advice. It would not lead to the most useful comparisons.

Methodology: Baseline Settings Used for Visual Comparisons

"Baseline" Settings

Our baseline Cyberpunk 2077 2.0 screenshots use ray reconstruction. Accessing the ray reconstruction toggle at all requires starting from the RT Overdrive preset, so that's what we did, but with film grain, chromatic aberration, depth of field, lens flare, and motion blur turned off. DLAA, dynamic resolution scaling, and all non-DLSS forms of upscaling (FSR, XeSS) were disabled. DLSS frame generation is on by default as part of the RT Overdrive preset; we left it on for our baseline. All settings were kept at baseline values for these screenshots unless specifically noted.

"No Ray Reconstruction" Settings

On the screenshots marked as having no ray reconstruction, all other settings were left at baseline as specified above: only ray reconstruction was toggled.

"Native" Settings

For the screenshots marked "native," all DLSS features were disabled, including upscaling, ray reconstruction, and frame generation. This is what NVIDIA has used as a visual comparison against DLSS 3.5, as well as suggesting that reviewers use it for performance comparisons. That isn't relevant or fair, so our comparisons will focus on our baseline settings with ray reconstruction toggled on and off.

This capture is just for visual comparison, NOT performance analysis. We'll cover performance separately in a moment. All screenshots shown here have been cropped from 4K originals; we highly recommend that you at least scrub through the accompanying video for full-frame comparisons of the clips in motion.

Finally, we encountered a ton of bugs in the settings menu of our press build, too numerous and boring to list. We suggest you verify all of your graphics settings after changing presets, changing any individual setting, applying changes, or relaunching the game. You should also check them after running the benchmark, because they can reset after applying and before running the bench.

Using the Image Quality Comparison Tool

These comparisons will use an embedded side-by-side image comparison tool from the software ICAT, which is a vendor-agnostic software solution to make it easier to compare images. We have inspected the ICAT code and have found it to be neutral, despite being made by NVIDIA. We have modified the ICAT javascript to work better in web format. Our video comparisons (for the YouTube upload) were made entirely in Adobe Premiere and show the same results.

The interface for the below comparisons includes an image selection drop-down in the bottom of the viewer. You can change the images there. The top-left contains a side-by-side comparison or split-screen comparison. You can also zoom or drag the slider.

Comparison Screenshots

Scene: Driving

(By default: Left is the baseline with ray reconstruction on, right is the test with ray reconstruction off. Both images are cropped to avoid additional scaling.)

Ghosting behind car side mirrors was one of the NVIDIA-provided examples of problems which should be solved by ray reconstruction. We found that we needed to stick close to its example to see the effect: the Porsche 911 II moves quickly and has a dark side mirror that projects out from one side, which is ideal. Zooming in on the side mirror and watching it in motion reveals a streak behind it, too light or too dark depending on the surrounding lighting. The effect is lessened by ray reconstruction, enough to make it less noticeable. The movement here is critical to really seeing this impact, so be sure to check the video accompanying this piece. This is a best-case scenario, though: when we tried cars with smaller mirrors, which is most of them, there was less ghosting to begin with. Ray reconstruction more significantly reduced ghosting on the tail light illumination on the road surface, but it still didn't eliminate it: notice how the streak of red extends back from the car in motion. 

Reconstruction sharpens headlight-illuminated vegetation, seen most clearly at the beginning of the clip and the very end as the car veers off the road. In motion, the outlines of the headlight beams are more clearly defined with reconstruction, especially on the right where the beams pass over grass and gravel on the shoulder.

Below: By default, Left is the baseline with ray reconstruction on, middle is with ray reconstruction off, and right is the test at native. All images are cropped to avoid additional scaling.

With or without ray reconstruction, there's also a dark streak that incorrectly trails behind the car as it passes under lights, but ray reconstruction does an excellent job of recreating sharp car-shaped shadows to the side as it passes the gas station lights. Without ray reconstruction, these shadows are completely erased.

As the car passes the gas station, we see some extremely prominent ghosting on the overhead streetlights that ray reconstruction does nothing to address, but this is due to regular old DLSS: running the game at native without DLSS features eliminates that problem. The native capture does show significant tail light and side mirror ghosting, though, confirming that those are due to RT denoising.

So far, ray reconstruction has at least done as well as the old denoisers in a straight A/B comparison, and at best has shown improvement.

Scene: Overpass

(By default: Left is the baseline with ray reconstruction on, right is the test with ray reconstruction off. Both images are cropped to avoid additional scaling.)

In theory, reflections should be the simplest, most obvious comparison to make, but there's a reason we didn't start here. With ray reconstruction, the reflections in the sidewalk become sharper, most noticeable with the yellow barricade in the center and the garbage next to it. The thin, dark lines in the reflection of the barricade are the sort of detail that's lost without reconstruction. The more noticeable effect is that the outlines of every speck of water and crack in the sidewalk are sharply lit with ray reconstruction, which leads to a kind of oil painting effect.

One area of definite improvement is the oil drum and pile of garbage under the road. This is an ideal use case for ray reconstruction: the thin, dark shadows under the cardboard and oil drum are wiped away by the old denoisers, but not with ray reconstruction.

Scene: Sidewalk

(By default: Left is the baseline with ray reconstruction on, middle is the test with ray reconstruction off, and right is with native. All images are cropped to avoid additional scaling.)

The next scene is on the sidewalk. Ray reconstruction is visible here in the reflection of the rotating billboard on the wet sidewalk, with text and images more clearly defined, but there's also arguably an oversharpening effect over the whole reflection. For ray reconstruction to have a clear win here, the puddle would need to fully cover the entire sidewalk and provide a completely smooth surface. Ray reconstruction in our baseline recording also appears to cause heavier ghosting and smearing around distant cars and pedestrians at the far end of the sidewalk directly in front of the camera, visible without zooming in. Remember that this isn’t always the case—it’s very situational.

Examining our "native" recording without any DLSS features, the reflected rotating billboard is indeed blurrier than with ray reconstruction, so reconstruction can help. There's also still ghosting and distortion around distant NPCs and cars in the native recording, so this should be an issue related to RT denoising that ray reconstruction could address, but it appears to make things worse here.

Scene: Default Benchmark

We recorded passes of the baked-in benchmark for comparison, but we noticed that the smoke effects in the bar and alley varied heavily between scenes even with identical settings, so the majority of the benchmark is invalid for visual comparison. Instead, we'll skip ahead to the portions we can compare.

(By default: Left is the baseline with ray reconstruction on, middle is the test with ray reconstruction off, and right is done at native. All images are cropped to avoid additional scaling.)

As the camera flies over the puddle in the alley outside the bar, we see almost the reverse of the scenes we've looked at so far: with ray reconstruction, the edges of the puddle are blurred out and blended into the sidewalk texture. The reflections within the puddle are sharper with reconstruction and contain less ghosting around the reflected objects, but ray reconstruction also introduces its own ghosting artifacts behind the dark cracks in the sidewalk.

(By default: Left is the baseline with ray reconstruction on, right is the test with ray reconstruction off. Both images are cropped to avoid additional scaling.)

We noticed one prominent bug that we replicated across multiple recordings: as the palm trees in the final portion of the bench draw nearer to the camera and load higher detail models, the trunks blink in much darker than they should be, then fade back to a normal color. This only happens when ray reconstruction is enabled, and it happens to every tree in the scene.

We also recorded some footage with DLSS set to Ultra Performance (all other settings baseline, including ray reconstruction on), as opposed to the Quality setting we used for the rest of our capture. NVIDIA has stated that it has a “plan to train DLSS Ray Reconstruction to support Ultra Performance," so presumably it isn't ready for primetime, but it can be enabled. Based on this footage, we wouldn't recommend it. Ray reconstruction serves to highlight the low source resolution, turning the palm trees shimmer like AI animations. There's a screenshot of DLSS Ultra Performance accessible in the comparison tool above, but the problems are easiest to see in motion.

Scene: Club

(By default: Left is the baseline with ray reconstruction on, middle is the test with ray reconstruction off, and right is done at native. All images are cropped to avoid additional scaling.)

With ray reconstruction on, this bright club is less blown out by the sheer number of lights present in the scene. With it off, it’s all super bright and makes certain things look flatter, like the AC unit in the top right. We made note of this in our previous RT Overdrive video, and it’s still hard to say which is more “realistic” since the entire ceiling is covered in lights.

However, we think the new ray reconstruction looks better in general here. The added depth from shadows in various creases and crevices is more pleasant to look at, and the shiny couches look sharper and less hazy than with it turned off. There’s also another instance of gritty detail being wiped out though—the nearest couch is supposed to have some dirt or wear on it, but it’s mostly gone with reconstruction on.

Scene: Bar

(By default: Left is the baseline with ray reconstruction on, right is the test with ray reconstruction off. Both images are cropped to avoid additional scaling.)

Moving on to this bar scene, baseline with ray reconstruction looks sharper, as seen in all the foliage and the bottles on the shelf just inside the window. It’s also generally shinier, like in the tops of the kegs behind the bar and in the taps on the right side. The reflections themselves are better, like on the counter under the bottle shelf and the bartender’s hand.

With ray reconstruction on, several objects look more grounded in the scene, like in the ashtray, bottles, and glasses on the near bar. The bartender’s clothes also have more depth with shadow under his collar and more definition in the sleeve of his shirt. In the background and just over his shoulder, there’s more detail in the other building’s interior with ray reconstruction on.

It’s not all good though. We noticed some gritty and worn detail on the metallic bar stools disappearing with ray reconstruction on, as if it thinks it's getting rid of noise when in reality it’s supposed to be there.

Scene: Car

(By default: Left is the baseline with ray reconstruction on, right is the test with ray reconstruction off. Both images are cropped to avoid additional scaling.)

This next scene with the red car has a good mix of near and far elements. First off, ignore the terrible reflection in the car’s window—it looked like that no matter what we did. Baseline with ray reconstruction again looks sharper and shinier. We think it looks good on the shelter to the left side of the screen—the highlights on the roof are brighter and the lantern in particular looks better to us.

The overall effect can be too much though—looking at the front fender area shows us the much improved reflections, but also the extremely sharp highlights on edges in a way that looks like it’s trying too hard. Moving to the car’s door, we can also see the metallic flakes in the paint turn into bright points of glittery light with ray reconstruction turned on.

One last thing to point out is the heat haze effect over the fire. Without ray reconstruction, we see lots of shimmering and warping over the flames, but with it turned on, that behavior is almost entirely wiped out.

Scene: Float

(By default: Left is the baseline with ray reconstruction on, right is the test with ray reconstruction off. Both images are cropped to avoid additional scaling.)

The Arasaka parade scene is one of our favorites. Ray reconstruction gives the whole float a more golden color from the numerous lights onboard, there’s more light on the underside of the roof, and the big metal chicken picks up a lot more reflections. Speaking of reflections, we again see more detail in the reflections around the edge of the float, more accurately showing the wood paneling and flags above it.

While most of our examples show increased depth and definition, the triangular area on the side above the awning appears much flatter and muddier with ray reconstruction on.

Once the float passes, the buildings in the background show observably more contrast and sharpness. Finally, the firework of the Arasaka logo appears much brighter with ray reconstruction on, with the individual points of light blooming to a much higher degree than with it off.

Scene: Servers

(By default: Left is the baseline with ray reconstruction on, right is the test with ray reconstruction off. Both images are cropped to avoid additional scaling.)

In this server room, we see a mixture of good and bad from ray reconstruction. Edges throughout the scene pop out more with the feature turned on, and the reflection in the floor is sharper. One of the most annoying negative effects is the smearing around the trailing edges of the player’s gun model—it’s present in both, but is decidedly worse with ray reconstruction on.

On the positive side, reconstruction cleans up the rolling shimmering effect of the thin horizontal lines in the floor at the left side and middle-right of the screen and adds a shadow (in addition to the usual reflection) under the dropped gun.

Let's take another look at this scene, but with some motion added in. Without ray reconstruction, the reflections on the floor become extremely grainy as the denoiser fails to compensate for motion. With ray reconstruction enabled, though, the reflections remain smooth even as the camera moves side-to-side. There's still a visible boiling effect in the wake of the gun and hand models, and there's additional ghosting behind dark lines on the floor, but it's preferable to the alternative.

Cyberpunk 2.0 Ray Reconstruction Bugs

For our visual analysis, we focused on finding good, repeatable scenes that would show the benefits (if any) of ray reconstruction. In the process of recording footage though, we came across a few bugs. We're categorizing these separately because they have less to do with visual fidelity and more to do with being straight up broken.

We noticed some areas where transparent items became partially invisible with ray reconstruction enabled. The most obvious example is this fast travel point, where chunks of the hologram above it disappear: check out the left side of the hologram. This effect is really noticeable ingame, and fast travel points are extremely common, but the bug only manifests with certain surroundings. This screencap was taken in motion; see our video for the footage.

Looking at the same sign in motion, we noticed trails of light smeared over the fence behind it as we walked towards it. Again, this bug disappears when ray reconstruction is disabled. For a more obvious example we can look at the warning lights on this rooftop: they do leave small trails with ray reconstruction off, but the trails become ridiculously long with the setting enabled.

As we already mentioned, we saw some LOD-related lighting bugs in the built-in benchmark scene. We saw this elsewhere as well, like the roof of this shack. There's some visible pop-in with ray reconstruction off, but with it on, giant black areas flicker over the roof as we get nearer.

Finally, there's an ongoing issue with ray-traced lighting appearing extremely bright after loading a save or exiting a menu. This one ISN'T due to ray reconstruction—it happens even with all DLSS features disabled—but it's one of the most common graphical bugs remaining in the game. The faster the game is running, the faster the lighting is calculated, and the less severe this effect will be.

Also, if CD Projekt is reading, PLEASE fix the settings menu. Individual settings get reset constantly for inscrutable reasons. We've had situations where we applied settings, clicked "run benchmark" in the settings menu, and the settings at the end of the bench were different from the ones we'd set at the start. It's extremely difficult to have confidence that the settings are ever what they say they are.

Cyberpunk Ray Reconstruction Benchmark Performance

Note that these tests had altered settings from some of the above-defined settings, which were for capture specifically.

In this quick set of benchmarks, we have 4 entries. In the frame generation ON tests, we see ray reconstruction technically had an uplift for performance. There’s a reason for this—we’ll get to it.

Frame generation ON testing showed a similar result. The Frame Gen off scenario posted an 8.6% gain with ray reconstruction, while FG on posted an 8.5% gain. That’s remarkably consistent.

Note that games with multiple ray-traced effects may have several denoisers that are replaced by the single Ray Reconstruction neural network. In these cases, Ray Reconstruction can also offer a performance boost. In titles with less intensive ray tracing and fewer denoisers, Ray Reconstruction improves image quality though may have a slight performance cost.

NVIDIA

As for why, our best bet is that this has to do with the denoisers. Speaking with NVIDIA, this behavior is expected sometimes—like in Cyberpunk—but not always. It’s possible that certain settings configurations, test areas, or just other games will have negative results. In this particular test, the removal of Cyberpunk’s multiple denoisers for ray reconstruction is leading to a net performance advantage. However, and we really want to stress this, even NVIDIA says that other games may show performance cost. This particular execution benefits, though.

Conclusion: Whether Ray Reconstruction is Worth It

RT denoising flaws exist regardless of whether upscaling occurs. NVIDIA seems invested in implying that ray tracing, frame generation, ray reconstruction, and DLSS upscaling all go in one big bucket (to be fair, AMD does the same thing). Upscaling isn't inherently part of RT, though. Upscaling makes RT more usable at a playable frame rate, but it also amplifies the flaws of existing denoising solutions, a lot of which are manually tuned by game developers to work for a specific game. This creates a greater need for something like ray reconstruction to patch up those flaws: fewer pixels at the true render resolution means fewer rays and fewer samples for the denoisers to work with.

Ray reconstruction is pretty simple as a feature. First of all, there shouldn't be a big performance impact, if there is one at all. In this particular instance there's actually performance uplift. That's going to vary game by game, but it shouldn't ever cost much from a performance standpoint. 

In general, we think it looks the same or better when compared against the same settings (DLSS enabled) with only ray reconstruction turned off. There are instances where it looks worse, but it's never that much worse, or at least not in this game. This is basically a free minor upgrade, and from that perspective it's pretty inoffensive. It can look better than native sometimes because of how ray reconstruction works in tandem with other features, and if you disagree, you aren't required to use it. 

Comparing versus native isn't really valid, though: there are only a couple of ways to test a proper A:B comparison, which we did. We don't agree with NVIDIA's review guide; we typically don't read them, but in this instance there were so many bugs that we felt we had to.

At the end of the day, we think that the overall effect is positive. Those of us that play Cyberpunk plan to enable ray reconstruction when we play Phantom Liberty. Phantom Liberty is on our radar next for Cyberpunk (that's a separate embargo, of course), and we may be benchmarking that one. Check back for all of our additional coverage coming up, and watch our Starfield content if you want to see DLSS and frame generation modded into that game.

Our performance optimization & graphics guide for Starfield finds the balance between visuals & FPS

The Highlights

• Multiple settings can be tweaked without much loss
• At least one setting appears to be bugged
• Modding is critical for the best experience
• Release Date: September 6, 2023

Those who have been with us since at least 2015 may remember that some of our original success came from optimization guides and benchmarking for the PC releases of GTA 5 and The Witcher 3: Wild Hunt. Eight years later, we're back with Starfield.

This massive graphics guide looks at the mod packs that are out now, including DLSS and an optimizer mod. We'll also be looking at graphics comparisons A-to-B, doing a ton of benchmarks across different graphics settings presets, and explaining a deeper level of optimization you can do beyond the presets. This is the final installation of our Starfield coverage for now, but as more mods and patches to the game come out, we'll revisit. You can find our prior GPU benchmarks for Starfield here. We also ran CPU benchmarks for the game in a video.

We're going to look at each setting individually, comparing them not only visually but with a number of benchmarks across different platforms, including both CPU- and GPU-bound setups. We'll be testing the graphics settings and tuning them from two directions: firstly from a baseline of 1080p Low, meaning adjusting the setting under test upwards, and secondly from a baseline 1080p High, meaning adjusting the setting under test downwards. 

We'll also be looking at some mods. Optimizing Starfield's graphics can go a lot deeper than just configuring the in-game menu. You can get into fine tuning parameters like maximum decals, the draw distance per item category, mesh culling, the radius of things such as ambient occlusion, the shadow map count, the particle count, and more. These individual settings have already been tuned by one of the mods we'll be testing. In addition, we'll test two DLSS mods, as well as a quick test with an FOV tweak.

Credits

Host, Writing, Testing

Steve Burke

Testing, Writing, Research, Web Editing

Patrick Lathan

Testing, Writing, Research

Jeremy Clayton

Video Production

Vitalii Makhnovets

Starfield Optimization Overview

One quick thing right at the top: as we were finalizing this piece, Bethesda posted a note that said it’s working on official DLSS integration, an FOV slider, HDR support, and gamma adjustments. These are not integrated yet. It did post a small patch (1.7.29), but none of these features were included. The patch claimed improvement to performance without being specific. 

We ran two quick validation tests and found that the RX 7600 had no change to performance when tested at 1080p High or 1080p Low in our conditions. The RTX 4060 saw a 6% performance uplift in one test, but upon running NVIDIA Profile Inspector, we found that this is because NVIDIA pushed a patch (not a driver update) that flagged Starfield as resizable bar compatible. The 6% uplift could be a mix of ReBar with whatever Bethesda changed, or just from ReBar. Either way, as of right now, there are no major changes from the patch—it’s mostly to fix a few quest-breaking bugs. Patches won’t affect most of the graphics comparison or relative performance values anyway.

Starfield Graphics Performance vs. Visual Impact Summary

We created a summary chart of our findings. Some of these matters are subjective, like our opinions on visual impact. Please note that this chart is for your quick reference, as the content here today is in-depth and aims to provide a detailed understanding of the settings and of how to tweak Starfield for better performance. These types of summary charts strip all nuance from what they contain, so we ask that you read on for context.

The scale ranks from "None" to "Critical." Performance impact is defined objectively and from our GPU-bound test scenario; however, CPU-bound scenarios are explored later. The performance impact rankings are objectively defined by the ranges below. Some have caveats, like grass and crowd density. Indirect Lighting is also a particularly interesting one for visual impact: Most of the time, it’s not too noticeable, but there is one specific condition that really ruins the visuals for us.

We’re providing this summary chart because we don’t want to offer flat recommended settings. That’s because it changes based on the hardware, so rather than recommending a safe configuration that everyone can probably run, we’re giving you the tools so that you can tune it for your system. A higher-end machine might only focus on critical performance items for extra framerate, while a low-end one might focus on moderate to critical.

The testing we're doing today is relative scaling from impact of settings, which means that this will remain a permanent reference unless Bethesda makes very specific tweaks to how some of these settings behave.

A lot of our testing was done with an RX 7600; we have 4090 results in here as well, but that comprises the bulk of the numbers we're looking at today. Driver updates aren't going to change the relative scaling of individual settings, although absolute framerate numbers will change.

Enough of the summary. Time to show our work.

Starfield GPU-Bound Graphics Benchmarks

For this, we’re looking for any change greater than a couple percent to investigate an individual option. We’ll start with our New Atlantis testing, then move to other regions based on setting.

Important: All screenshots shown here have been cropped from 4K originals as a practical matter for web hosting; we highly recommend that you at least scrub through the accompanying video for full-frame comparisons of the clips in motion. All capture was done on an RTX 4090 at 4K in borderless windowed mode, which is the closest thing to fullscreen that's available in the (unmodded) game as of now. Our baseline capture was done with all settings manually maxed out, with the exception of v-sync, all forms of upscaling, variable rate shading, film grain, dynamic resolution, and sharpening, each of which were turned off (motion blur and depth of field were left on). This only applies to the capture done for visual comparison, not the performance tests, which we'll cover later. All capture and commentary was done on the launch version of the game, which (as of this writing, post launch) has not yet received any patches.

GPU-Bound Optimization Tests

Moving to GPU-bound benchmarks with the AMD RX 7600, we’ll start with baseline Low testing and adjust each setting up individually. We’re starting in our New Atlantis test location.

First, we’ll just dump all the tests on a chart, then split them up accordingly. Look at this graph like a shopping cart: Each item you add costs performance, and we’re looking at that cost on a per-item basis.

Some settings, like grass quality, don’t have any impact in this test area—but they will later. We’ll split them out separately for testing in a field. Others, like motion blur, don’t affect performance in any meaningful way in any location. We saw the biggest impact from shadow quality, where changing literally only that setting to Ultra cost us a staggering 18% of our total possible performance with this setup. This is the first setting to adjust if you’re GPU-bound. Volumetric lighting would be next, then reflections and indirect lighting, the latter of which also has a potentially large impact on visuals when using Low and no variable rate shading. We’ll come back to that.

Jumping quickly to the GPU bind from the other direction, with a 1080p High baseline, we get this chart. We’ve intentionally sorted this chart with baseline at the top, despite it not being the best setting. This is the opposite direction: we start at High settings—not Ultra—and then reduce them as we go. That restricts the maximum top-to-bottom swing, but attempts to look at this more holistically. Reducing volumetric lighting had the largest improvement going from High to Low (when ignoring Ultra settings), with Medium volumetric getting most of the performance without as much sacrifice. Reflections and shadow quality were also high on the list, as was indirect lighting.

Note that several items, like everything in the 55-56FPS range, are within error of baseline. In other words, changing them had no impact on performance in this test scenario. We can see some changes in other areas, but not always. Let’s move to the individual charts.

Shadow Quality

Shadow Quality - Performance

Shadow quality has a particularly high cost at Ultra when tested with our GPU-bound configuration. Medium and High are barely differentiated, respectively costing 4% and 7.5% of the baseline performance. 4% is still a relatively large change considering it’s just one setting, but Ultra remains the obvious choice to avoid for most setups. If you’re on higher-end hardware that can almost handle the Ultra preset, you could drop shadow quality and likely boost it to more satisfactory performance.

Looking at shadow quality from a High baseline rather than Low, we saw a 5.5% improvement by switching to Low shadow quality, which materializes as about 3FPS AVG. Moving to Medium gave us a 2.5% uplift. Ultra obviously was more expensive. Let’s take a look at what shadow quality actually does.

Using the Image Quality Comparison Tool

These comparisons will use an embedded side-by-side image comparison tool from the software ICAT, which is a vendor-agnostic software solution to make it easier to compare images. We have inspected the ICAT code and have found it to be neutral, despite being made by NVIDIA. We have modified the ICAT javascript to work better in web format. Our video comparisons (for the YouTube upload) were made entirely in Adobe Premiere and show the same results.

The interface for the below comparisons includes an image selection drop-down in the bottom of the viewer. You can change the images there. The top-left contains a side-by-side comparison or split-screen comparison. You can also zoom or drag the slider.

Shadow Quality - Visual

Below, in order of LEFT to RIGHT: (1) All settings max (Baseline), (2) shadow quality high, (3) shadow quality medium, (4) shadow quality low. All images are cropped for web. View the video for full resolution.

The most obvious results of the shadow quality setting can be seen in the edges of shadows, which generally become softer as the setting is lowered from Ultra to Low. Fine details like the shadows of chair legs are blurred out at Low, as are the shadows of individual leaves at the bottom right of the frame. The differences between Medium and High are more complex, with shadows on the wall at the right of the frame appearing softer at Medium, but sharper under the table and chair at the center.

Below, in order of LEFT to RIGHT: (1) All settings max (Baseline), (2) shadow quality high, (3) shadow quality medium, (4) shadow quality low. All images are cropped for web. View the video for full resolution.

Indoors, where shadows are generally closer to the source casting them, the scale from Low to Ultra can be more subtle. Moving from Ultra to High practically erases the shadow of the coffee table cast by the fire, but otherwise there's little difference. Medium is similar, but moving to Low then removes much of the shadow under the portrait cast by the ceiling light.

Below, in order of LEFT to RIGHT: (1) All settings max (Baseline), (2) shadow quality high, (3) shadow quality medium, (4) shadow quality low. All images are cropped for web. View the video for full resolution.

Shadow draw distance also scales with quality. Even just going from Ultra to High in this scene eliminates many shadows within the tree canopy in the background, and each step down in quality brings the edge of that draw distance closer, until at Low even the shadows within the trees closest to the camera are almost gone.

Indirect Lighting

Indirect Lighting - Performance

Indirect lighting doesn't have as large of a performance impact as some other settings, but it does have a gigantic impact on visuals depending on which setting you use. Low (with VRS off) produces some of the worst looking blurring in the game, so older GPUs that don’t support variable rate shading will look particularly bad at Low.

For performance, though, we’re seeing about a 5.8% performance loss by going from baseline Low to Ultra indirect lighting when GPU-bound.

Switching to baseline High and still GPU-bound, moving from High indirect lighting to Low gave us 4.2% more performance. It does have a big visual impact, so let’s look at that.

Indirect Lighting - Visual

Below, LEFT is all settings max (baseline) and RIGHT is with indirect lighting on high. Use the drop-down in the bottom corner to add other settings (if present).

Indirect lighting at Low is so ugly that we think the setting itself might actually be bugged (at the time of writing). It shows no meaningful difference between Ultra and Medium in any area we checked. Then, at Low, it suddenly looks jagged, shimmery, and flickery anywhere there’s a line. Areas of the screen appear blurry and low-res, especially noticeable in the background high-rise and the metal awning over this balcony. For what it's worth, the effect is strongest in areas that actually are indirectly lit—shadows illuminated by reflected light.

Below, LEFT is all settings max (baseline) and RIGHT is with indirect lighting on high. Use the drop-down in the bottom corner to add other settings (if present).

This scene in a park shows the same effect: distant objects like the Mercury Tower sign in center screen become a watery mess, while some other objects are only affected on the edges, like the blue pillars in center screen. This really does look terrible in game. If you've been running this setting at Low, we highly recommend pushing it up to Medium. It may change your perception of the graphics overall and should be one of the first settings to try increasing. Alternatively, enabling Variable Rate Shading also solves the issue, which makes it seem even more likely that it's a bug.

Below, LEFT is all settings max (baseline) and RIGHT is with indirect lighting on high. Use the drop-down in the bottom corner to add other settings (if present).

We did notice that in some scenes, for example this club, the visual impact isn't clearly visible. There’s still some difference specifically at the lowest setting, though: notice the flickery noise in the reflections on the text encircling the stage. Again, moving to Medium makes the scene appear effectively identical to Ultra.

Grass Quality

Grass Quality - Performance

Time to get into grass quality. Our previous summary charts showed nearly zero impact from grass quality, but that’s because there’s not much grass in the New Atlantis scene. Looking at grass quality tested specifically in a field, we see the differences emerge more meaningfully. 

Tested from all Low settings at 1080p and only adjusting grass, without upscaling, the baseline result was 86FPS AVG with good lows. This field doesn’t put load on the GPU in the same way that the city does, but the grass quality clearly shows impact overall: increasing quality to Medium results in a loss of 2.4% performance, while increasing to High costs us a total (from low) of 6.9%, with Ultra costing 11% from baseline Low. That’s a massive swing considering this is just one quality setting. If you’re in a GPU-bound scenario and you particularly notice issues in grassy areas, this would be the setting to adjust: just know that it won’t help performance issues in areas without much literal grass, like cities.

Grass Quality - Visual

Below, in order of LEFT to RIGHT: (1) All settings on max (baseline), (2) grass quality on high, (3) grass quality at medium, (4) grass quality at low

Grass quality has obvious goals. It affects the "quality and lushness of grass," according to the Starfield settings menu, which translates to the distance at which blades of grass are drawn. As we lower the setting while looking over this field, with game restarts between each change, the draw distance shrinks and grass further from the camera is culled. We haven't seen a link to any foliage that isn't literally grass: some distant trees appeared and disappeared between recordings, but not in a way that correlated with the grass settings.

Below: LEFT is all settings max (baseline), RIGHT is with grass quality on high. Use the drop-down in the bottom corner to add other settings (if present).

This extends to the mossy growth in New Atlantis–it isn't grass, so there's no difference between the minimum and maximum settings other than the (possibly random) change in some far-away trees behind the silver statue.

Crowd Density

Crowd Density - Performance

Crowd density is our next setting to test. This setting has a high and observable visual impact, but a low impact on performance. We’d strongly recommend keeping this as high as you can to keep the game feeling more alive.

In a GPU-bound setting from a Low baseline, we saw a cost of around 2% to increase crowd density to High. It wasn’t worth testing anything in between since, obviously, it’d be less than a 2% swing. Let’s look at the visuals.

Crowd Density - Visual

Below: Left is max crowd size, right is medium. Use the drop-down in the bottom corner to add other settings (if present).

Our methodology for this piece was to change a setting, exit the game, open the game, load our save, and start recording. In this process, we noticed that Starfield is weirdly consistent about loading saves, extending to the positions and paths of NPCs. That explains why we didn't see any real difference in the number of NPCs between Low and High crowd density: we need to load into a new area and generate a fresh batch of NPCs, but that also breaks the side-by-side comparison we're trying to do.

By loading into the MAST district we can get an extremely rough picture of crowd density. We captured a couple passes at each setting, then synced them up, paused, and counted the visible NPCs in that single frame. With that small sample size, we saw 22 NPCs on average at High, 17 at Medium, and 13 at Low. Again, those are averages; the select screenshots above don't match those numbers. We can't base any performance calculations on those numbers, but it's enough to confirm that the setting does do something.

Reflections

Reflections -  Performance

Now for reflections. This is another one with a relatively high performance cost for a singular setting, depending on how bound you are on the GPU. Starting with the Low baseline numbers on the 7600, we saw a maximum cost of 7.2% moving to High reflections, or about 2.2% with Medium.

From the other direction, tested at a High baseline, we saw an improvement of 5.7% by dropping reflections to Low, or about 3% dropping it to Medium. Even with everything else loading the GPU heavily, reflections is still one of the first settings you could go to for a performance uplift.

Reflections - Visual

At the highest level, mirrored surfaces show a fairly sharp (but not ray traced) reflection of the surrounding space, while lowering the setting to Medium leads to more streaky, abstract reflections. Even at max, objects like the furniture and NPC aren't reflected at all here. Moving to the lowest setting wipes away large details and also appears brighter in this instance, although we ensured that each individual set of clips was done at precisely the same time of day. Note that the real pillar and floor visible at the right edge of the screen are lit the same at all settings: only their reflections change. There are some slight changes in non-mirrored surfaces as well, but there's not a clear better or worse setting in this regard.

This outdoor lake scene illustrates the same point: the surface of the lake and the exterior of the curved building are brighter with reflections at High, but Medium and Low are effectively identical, even when considering the reflections of scenery on the water's surface. Like some of the other settings in the game, it appears as if the biggest visual change is at the highest quality option.

Volumetric Lighting

Volumetric Lighting - Performance

Volumetric lighting benchmarks are next. When GPU-bound and from baseline Low settings, we see a performance loss maximally of 12%. This setting has a large impact on performance. High and Ultra cost about the same. Medium costs about 3.3% of baseline performance.

Tested from a High baseline instead, we saw a 9% performance uplift by moving from High to Low, about a 6.6% uplift going to Medium, and a slight loss going to Ultra. Even when more heavily constrained in general, this setting still has a large performance cost.

Volumetric Lighting - Visual

The smoky streets of Neon seemed like the ideal place to check for volumetric lighting, but they weren't: it's not the right kind of smoke. We'll use that scene to check some other settings.

Instead, let's look at a facility on Mars. Ultra and High look similar, bringing up the brightness and sharpness of the fog-shrouded lights at center screen, but dropping to Medium and Low progressively softens the effect, with Low eliminating some of the individual bright points altogether. There are flickering artifacts around one of the lights at all settings.

GTAO Quality

GTAO Quality - Performance

GTAO testing is next. For this ambient occlusion testing, we found that a GPU constraint from 1080p Low baseline resulted in a 4% performance loss by changing to Ultra for the setting. The range for this one is overall low, considering the relatively low maximum cost.

From High baseline, we found no change going to Low. The performance was within error.

GTAO Quality - Visual

The lodge is an ideal place to check on ambient occlusion, with lots of small objects cluttering the scene. This setting performed completely as expected: at Ultra, crevices behind cushions are darkened, as are areas around items on the coffee table and under pieces of furniture. The effect is lessened noticeably with each step down to High, Medium, and Low, with Low showing brightly lit areas that should definitely be in shadow, like inside the arms of the couch.

The effects aren't always so pronounced, though. Although the setting is still working as intended, this brightly lit office on Titan mostly shows ambient occlusion around the base of the desk. The complicated geometry of the office chair also benefits, with higher settings significantly darkening the areas underneath and inside the chair.

Contact Shadows

Contact Shadows - Performance

On to contact shadows. From 1080p Low baseline, we observed a 3.6% performance cost hiking to Ultra. That’s not a big range, and settling in between would yield most of the visual benefits.

From baseline High settings, reducing contact shadows to its lowest setting gained us 1.4%. It's not much worth considering when other options give far more range.

Contact Shadows - Visual

The most obvious instances of contact shadows that we could find were around NPCs in bright sunlight. In this regard, Ultra, High, and Medium look pretty much identical, while shifting to Low drops the resolution of the shadow where Vasco's legs contact the ground and eliminates some detail in the shadows in the arms and legs.

Elsewhere, the differences are even harder to notice. In this outdoor scene, the joints in the honeycomb roof structure become darker when the setting is raised above Low, but changes beyond that are minor. Most of the NPCs are standing in shadow, so even ones that pass close to the camera (like the security guard) are unaffected by the setting, and the ones in the distance are too far away to see clearly anyway.

Particle Quality

Particle Quality - Performance

For particle quality benchmarking, we found no differences from our baseline Low settings by increasing this setting. We even checked in some areas that seemed to more explicitly show particles, but found no differences.

Particle Quality - Visual

The setting is described as setting "the quality of particle lighting," so we tried examining three specific things closely: sparks from a mining laser, smoke backlit by neon signs, and sparkle effects on the artifact in a scripted sequence.

Starting with the mining laser, the sparks generated by firing it have no noticeable effect on any of the surrounding shadows at any setting. The laser itself does illuminate its surroundings, but there's no flickering or variability to suggest that the sparks themselves are lit. There's also not a difference in the quantity of particles generated at any of the settings.

Since we didn't see particles lighting the scene, we hoped to see the scene lighting particles by moving to the smoke in Neon. The differences are almost invisible, but we noticed that the cables in the support to the right of the Neon Security sign are obscured at the lowest setting, accompanied by some shimmering. Medium and High still look identical in this area.

Finally, in the animated sequence that starts after bringing the artifact to the lodge, there are visible differences in lighting and shadows between recordings, but flickering and intensity of the light appears to be randomized. We can't make a conclusion based on this scene.

Starfield CPU Bottlenecked Graphics Benchmarks

We’ll briefly look at benchmarks from the CPU-limited angle now (or a CPU bottleneck as opposed to our earlier GPU bottleneck in Starfield). For this, we chose an R5 3600 with an RTX 4090 to create a CPU-limited scenario.

Overall, we found most settings were unable to affect the performance. The best shot was shadow quality again. Even though it’s a GPU-heavy setting, it’s still affecting performance when mostly CPU-bound. Bottlenecks are rarely so simple as being one component or the other. crowd density also affected performance, but not much. We saw a 3.6% performance loss from baseline by going to High crowd density.

Otherwise, everything was within 1% change, or 1.2-1.3% for reflections and contact shadows. We tested these from baseline High also, but stopped because we saw no change.

Mods

Time to talk about mods. A couple weeks into launch and Nexus Mods, unaffiliated with us, is already filled with tons of options. We downloaded and tested a couple, each independent from the other. The mods we tested include:

• Starfield Performance Optimizations by E3roKK
• Starfield Upscaler for DLSS by PureDark
• Starfield Frame Generation by LukeFZ564
• Manual FOV adjustment in the .ini files

• Default FOV
• 150 FOV

We’ll do the simplest benchmark first. Field of view, or FOV, has been a common complaint since the game launched. It can be changed without modifying the game other than creating a custom .ini file, similar to Skyrim. Increasing FOV widens the peripheral vision of the player’s camera. We ran some quick tests from the default FOV up to 150. 

Between all of them, performance was the same. 150 looked awful, but it was just there for a test. We tried up to 360, but predictably, that didn’t work very well. Most people might adjust to 90-110, and in those cases, we found no performance loss.

DLSS Mods

Up next, we tested two different DLSS mods. We tested with up to DLSS 3.5, at least according to the DLLs, and used frame generation with the DLSS-G mod. Our baseline performance for this test was about 50FPS AVG on the test platform with an RTX 4060. Upscaling obviously improves performance since it’s reducing the base render resolution, so it’s no surprise that 79% render scale brought us up by 18%. 0.1% lows didn’t move here. Dropping to 70% improved us further, now to 62FPS AVG and an increase over baseline of 24%. Removing that mod and switching instead to the DLSSG Mod with frame generation, we saw an immediate increase of about 30-40FPS AVG. The 70% scale’s 100 FPS AVG is around our CPU limit on this test platform. Judging against the 79% increase, we saw an improvement of 57% over the test without frame generation, at 58 FPS AVG, or 85% over baseline at 100% scale.

If you’re using an NVIDIA card, these mods may be worth a look.

Optimization Mod

Up next is the Optimization mod. This one changes the actual implications of the named graphics settings, so Ultra/High/Medium/Low now carry a different set of parameters. That means the words themselves aren’t like-for-like, but that’s the point of this quick test.

The mod author noted that “it slightly tweaks some of the graphical settings like shadows, reflections, grass, npc spawning, non baked light counts, and VRS settings.”

The blue bar is the baseline, the red bar is the modded result. This is just for AVG FPS. As for the results, we found that Ultra improved the most: It moved from 44 FPS to 51, an increase of 16%. The Medium results posted a 12% improvement. Low barely moved.

It’s likely that this approach will get more refined as modders have time to really figure out the game. If you need more performance than you can get from the settings natively or want finer tuning between “Ultra” and “High” or other settings, this would be a good starting place. You can then tune it further for what you want.

There are also variations of this ini modding approach that increase graphics quality of Ultra.

Conclusion

A couple of these settings are particularly impactful in terms of performance, namely shadow quality and volumetric lighting. For the full picture, be sure to check our Starfield GPU benchmarks. The major takeaways from our day one benchmarking were that the RX 7900 XTX was unusually competitive with the RTX 4090, while further down the stack the RX 7600 and RTX 4060 each offered a decent price-to-(playable)-performance balance (especially the RX 7600).

In terms of visuals, indirect lighting is an interesting exception: in most cases it doesn't appear to do much, but at Low with VRS off it looks awful to the extent of ruining visuals. Fortunately, most people will use VRS, at least on newer cards. If you're on a card that doesn't support VRS or you don't want to use it, make sure you're not on low indirect lighting. Again, the setting may just be broken currently—that wouldn't surprise us with a Bethesda launch.

Contact shadows and volumetric lighting aren't broken, but they don't show serious improvement in quality above High for volumetrics and Medium for contact shadows. With volumetrics, it's a matter of opinion whether the higher settings look better. 

GTAO, shadow quality, and reflections all show clear differences at each quality level, and they all look their best when maxed out, so these are settings to focus on when balancing visuals and performance (especially shadow quality). 

We struggled to find any differences with particle quality. We found a couple of examples, one of which we showed earlier, but it doesn't impact performance in our test areas. 

Crowd density should definitely be maxed out if possible; it doesn't have the biggest impact on performance, and it really influences how alive the game feels. Grass quality also directly affects the quantities of grass and the view distance of it, so if you're doing a lot of exploring we'd recommend setting that one higher, but it does have a relatively high performance impact on the GPU in grassy areas.

This article is built to be a long-term reference for Starfield graphics settings. If you want more detail, watch the accompanying video for in-motion comparisons of the various clips that were screencapped for this article. We're not experts in tuning the Starfield config file for more granular options like shadow maps or draw distances, but there are a lot of experts out there and we highly recommend you check out Nexus mods as they develop. For now, though, this article should give you the knowledge you need to get the game running as well as it can.

We benchmark over a dozen CPUs in Starfield while exploring potential GPU and RAM bottlenecks

The Highlights

• There is some core scaling between six core and eight core CPUs in Starfield
• Older/less performant CPUs like the R7 2700, 3700X, and 12400 can limit the game’s performance
• Starfield is a clock-bound game that can benefit from CPU overclocking
• Release Date: September 5, 2023

Today we’re benchmarking CPUs in Starfield. This content became a lot more interesting than just a CPU benchmark. As a matter of fact, the CPU benchmarks were done in one really long day, but we added a lot more time to start exploring GPU Busy, which is the new frame time metric that we were talking about with Intel engineer Tom Peterson recently.

In terms of CPUs, we’re going to be looking at a bunch of SKUs, everything from the AMD Ryzen 2000 series up to modern CPUs like the 7800X3D. On the Intel side, we’re looking at the company’s 12th and 13th generation processors. We also spent some overclocking time using the 13900K just to try and see how much clock scaling there is in addition to CPU core count.

There’s a lot of real cool stuff coming your way. GPU Busy, in particular, will be a lot of fun to go through because it’s a new type of metric that we can learn from.

Credits

Test Lead, Host, Writing

Steve Burke

Testing

Patrick Lathan

Testing

Jeremy Clayton

Video Production

Vitalii Makhnovets

Writing, Web Editing

Jimmy Thang

Starfield CPU Overview

Our key focus will be on CPU benchmarking and that entails building a CPU bottleneck. In order to do so, we use a high-end GPU and high-end memory. Throughout this process, we also tested some memory bandwidth situations with the ultimate goal being to try and isolate as much load as possible onto the CPU.

It’s worth noting that at the time of this write-up, the game is only a few days old and it’s not officially launched yet, we expect there’s going to be a major patch at some point in the near future.

We've seen efforts to explain why the 7900 XTX performs nearly the same as a 4090 in Starfield, including theories about poor NVIDIA driver optimization based on low GPU utilization and low power usage (percent TDP). We're not testing those theories in this video: this piece is about CPUs, and the 4090 is still one of the best choices for benching CPUs. 

Some of the community discussion has centered around GPU-Z showing “100%” utilization for the GPU despite having lowered “TDP” reported in GPU-Z. We’ve also seen some discussion around low Windows task manager GPU utilization despite being seemingly GPU-bound, e.g. at 4K/High but showing 30% task manager GPU load on NVIDIA (or something). We won’t get into this today, but task manager uses a simple method for reporting this utilization. There may be one part of the core, like graphics_1, at 100%, but task manager will represent the total GPU utilization in summary as a much lower number.

Likewise, it’s possible for a GPU to be 100% loaded on one specific component and not pull full power. 

Regardless, we did a lot of utilization testing and ultimately determined that, for purposes of a CPU benchmark, we were in fact largely CPU-bound except possibly at the very top-end (like 5.9GHz on a 13900K). The game’s behavior is objective and testable even if it isn’t fully “optimized,” and the numbers are what the numbers are. 

GPU Busy

Now we get into some super exciting new data. We’ve never previously produced charts like what we’re showing today and we’re really excited to do it. We’re using the latest update to PresentMon, an open source tool, to illustrate the GPU/CPU load split in Starfield. 

A massive disclaimer here: This is a brand new type of data presentation for the reviews industry. As such, because we’re trying something new with data we didn’t have before, it’s very likely that these charts and our understanding of them will change with time. 

As we get into this: We verified that using the command line version of this tool has no impact on performance metrics, but there are some specific conditions that need to be configured to minimize impact. We did that configuration.

GPU Busy Ratio

We’ll start with the ratio chart first, then go to the roots. This is a little backwards but, from an educational standpoint, we think it’ll make it easier to absorb the objectives of this data. One very important thing: THERE IS NO “BEST” in this chart. It depends how you want to interpret it. If you want your GPU to be fully utilized, then a 1.0 result would be the “best,” but your CPU will be underutilized. You’re always going to have a bottleneck somewhere. But it’s just about balancing the component expense to try and maximize each part without leaving a lot on the table. There’s a lot more going on within the frames that we can’t see yet either.

Utilization

Now, there’s one large important thing here: GPU Busy can still show as high, or as GPU-bound, even if the GPU isn’t actually bound. Remember that while we walk through these charts. That’s going to be really important, because the GPU actually isn’t being fully utilized by Starfield. We’ll come back to that.

This chart shows the ratio of total frametime against GPU busy time. The maximum value is 1.0. In this chart, the closer the blue bar is to 1.0, the more GPU utilization we’re seeing. The red bar indicates non-GPU work per frame rendered, whereas the blue bar represents GPU occupancy or busy time per frame rendered. A shorter blue bar means less GPU utilization as a result of the CPU being overloaded, which tells us that there’s an imbalance in the resources for the game.

So, for the 13100F, we can see a 0.57 ratio of average GPU Busy divided by average frametime. What this chart tells us is that our 1080p/low benchmarking will bind every component heavily on the CPU up until about the 13700K and 13900K, where we’re beginning to occasionally bounce off of a GPU bind. That means these parts are close to their maximum scaling in the CPUs before we get limited methodologically in our ability to demonstrate a meaningful difference.

GPU Busy Frametimes

Let’s look at the raw data. This will set the groundwork for future use of this, so you’re seeing the development of a new paradigm for us. We’re excited for it because we’re not sure where it’s going yet, but we can see the foundation for something useful.

This first chart is for the 13100F at 1080p/low. This is just a snapshot of 500 frames from the test -- we have a lot more, but limited the X axis to make it easier to read. The average FPS for the entire set of 4 passes came out to 81.8 out of a maximum on this GPU of about 145. The distance between the red and blue lines indicates that, in this chart at least, we’re CPU-bound. The GPU is not fully occupied during the creation of these frames and has time that it’s waiting on the CPU.

Let’s go to the opposite viewpoint: Here’s the 13900K at 1080p/low. We’re using a much higher-end CPU. The lines are almost on top of each other, aligning with our 0.95 ratio earlier. This indicates that our GPU utilization is much higher than with the 13100F -- which makes sense, seeing as it’s a 4090. The overlap tells us that we may not be able to see a fully decoupled framerate out of the 13900K at 1080p/low because we are still at least occasionally hitting a GPU bind.

The cool part about this is that it helps us frame our writing around the data: We can now more confidently indicate to you all whether we’re actually GPU-bound or whether we’re just capped on the CPU. In this case, we’re approaching and sometimes hitting a GPU bind, which means (of course) that the 13900K might be able to stretch a little further and distance itself from the rest of the pack slightly more if only it had a GPU that doesn’t exist or was on ridiculously low settings.

And now for those settings: Here, the 13900K at 720p/low -- which we recognize is a completely stupid combination of things, but is useful as an academic exercise -- is now establishing a gap between the GPU Busy and Frametime lines. This reinforces our earlier newfound understanding: The lower the ratio, the lower the GPU utilization. The higher the ratio (or closer to 1:1), the higher the GPU utilization.

Let’s look at one last one.

This is the 13900K at 1080p/ultra, so we’re definitely GPU-bound. Here, the lines are effectively right on top of each other. The ratio for this result was 0.99. It is effectively fully GPU-bound.

This stuff is crazy cool and we’re really excited about it. It’s a paradigm shift in the making for component benchmarking, and the industry is only just now at the front edge of figuring out how that shift manifests. We’re excited to see where the reviewer community goes with it, and on our side, we’re already planning to integrate it with most of our content going forward. Make sure you watch our engineering interview with Tom Petersen to learn more about the render pipeline.

As for what all this tells us: This game becomes very GPU-heavy (and rapidly) as settings increase. There’s not much of a middleground transition. It tends to be either GPU-heavy or CPU-heavy at the extremes of the settings.

Coming back to the utilization thing we talked about: We saw when the game was GPU-bound vs bound by other components. But the GPU utilization is suspect.

Starfield RAM Tests

Buildzoid shared a theory after seeing CPU tests from another outlet that there may be a utilization issue in regards to RAM, so we dove into that.

For our tests today, we’re not memory-limited on our CPU benchmarks. We did see some other numbers online that used very low-end memory, and in that case, they are memory bound. We think it was PC Games Hardware that used DDR5-4400 in their charts, which would be a limitation. Buildzoid is absolutely right about that. That’s still valid information, but it does restrict the scaling on the CPUs alone to more complexly include memory as part of the limitations and become more of a memory benchmark. What that test taught us is that memory can impact Starfield in large ways, so we wanted to make sure ours wouldn’t for a CPU comparison.

We didn’t spend much time on memory and only used a few different kits to rapidly see if there’s any meaningful change with our test setup. All we care about is eliminating as much of the memory and GPU bottlenecks as possible to focus on the CPU to see scaling. We also talked with Buildzoid about some of these theories -- we’ll come back to that after this chart.

First, here’s the chart at 1080p/high with a 13900K. Here, you can see we are completely bound on non-memory components -- that’ll turn-out to be the GPU, as you’ll see later. Memory did not affect our results outside of run-to-run variance here.

Here’s our 1080p/low chart. We didn’t do any tuning here. Our standard kit is the DDR5-6000 Corsair kit at 30-36-36-76, which we use in all our CPU reviews and tests. As you can see, it was within run-to-run variance of the DDR5-6400 kit at 32-38-38-76. We also have a custom V-Color kit that the company gave to us when we visited previously. As far as we’re aware, it doesn’t have an existing SKU on the market. At DDR5-7000 and 38-48-48-126, we were within error of our prior two kits. We had one more test at DDR5-5600 -- this is worse than our standard Corsair kit. After seeing no change in the prior tests, we decided to leave the looser timings and drop the frequency to see what happened. Here, we did get movement -- and a lot of it -- but what really matters is that, for our testing, we do not appear to be memory-bound.

As for the SK Hynix kit, for that, Jeremy on the team manually configured it at DDR5-6400 and 34-40-40-84. This is a dual-rank kit, so we used it just in case. Ultimately, although technically higher in framerate, it fell within our usual run-to-run variance.

If you were to run DDR5-4400 or some other slow speed, you’d probably get bound-up on a higher-end i9 CPU. This test isn’t definitive and it wasn’t our main goal to do a memory test with Starfield. All that mattered to us was determining if our standard memory kit was meaningfully limiting us from showing CPU scaling, and that answer is “no.”

We spent a couple hours working with Buildzoid on the next ideas. Although memory can still be a factor in our testing, we began looking elsewhere. He suggested a few tests:

• Disable hyper-threading
• Disable E-cores
• And overclock the 13900K CPU to 5.9GHz

We tried each of these independently and combined with help from Buildzoid to dial-in the overclock settings for rapid testing. Here’s what we came up with. This testing was done with our SK Hynix kit, which is different from what we’re using later in the charts. This testing is also done with 50% scaling against 1080p with FSR2, which is an abominably low resolution and some of the worst visuals we’ve seen in a video game -- BUT it’s intentional. We wanted to ensure we were not GPU-limited.

Our baseline result with these settings was 147.9FPS AVG. Disabling hyper-threading hurt the 0.1% lows, but did not affect the average framerate. Overclocking to 5.9GHz with HT off boosted us to 155.4FPS AVG, an increase over stock of 5.1%. It appears we’re clock-bound. Adding a cache overclock to 49x boosted us to 156.1FPS AVG, mostly error of the prior result but possibly an improvement. Disabling E-cores hurt the performance to below stock, even in spite of the overclock -- although it’s possible that E-cores off with hyperthreading on produces a better result.

We also ran these numbers with an RX 7900 XTX, yielding about the same maximum improvement over the 4090 as we saw in our tests earlier -- about 3.7%. But the improvement over baseline indicates that we were CPU clock-limited and overclocking helped here.

One thing we learned is that we were definitely clock-bound at the upper-end of our results, not GPU-bound. Now it’s time to get into the CPU benchmarks we’ve been promising.

Starfield CPU Benchmarks

Remember that these are accurate as tested regardless of the game or the driver’s issues right now. These still give you insight as to how it performs. We expect this will change as they patch things, so if you’re reading this in the future, you may want to check if we or others have newer data.

For this testing, we’re using 1080p/low as the extreme to show full scaling, then 1080p/high to produce a more realistic use case. You could estimate that medium would be in between.

1080p/Low

Here’s the chart where we get the most scaling, but at the least realistic settings -- and that’s fine. We’re starting with the pure scaling. That helps people on older hardware have a better idea for limitations. And most of this hardware is going to be bound by the CPU, not other components -- especially the older stuff. Anything with DDR4 is on our prior CPU test methodology kit that we’ve previously shown to be a strong performer.

At 1080p/low, we’re starting to become limited at the 13900K level, with the 13700K occasionally hitting that limit. This would be boosted with an overclock, as we saw earlier. The R7 2700 establishes the floor, at 54 FPS AVG with these settings. To bring attention to a few other older mainstays, users of the R5 3600, R7 3700X, and more modern R5 5600 and 5600X have plenty to gain if running on lower settings or overpowered on the GPU.

X3D CPUs don’t appear to offer as much of an advantage as we’ve seen in other games, with the 7800X3D capping out at 124FPS AVG, leading the 7700X by 15%. The 7950X3D struggles with its usual oddities, despite using the core parking behaviors and the specialized OS setup that we detailed in our review. It’s OK, but not scaling for the price.

For some other comparisons, the R7 5800X3D leads the R5 5600X by 20%. The 13600K leads the 7700X by about 10%, with the 13900K leading the 13600K by about 18% until we start becoming bound on other parts.

Let’s move to more realistic but GPU-limited settings.

1080p/High

At 1080p/high, we’ve lost about 22FPS AVG off the 13900K’s ceiling and we’ve truncated the 13700K in the process. There’s also a 13900K with a 7900 XTX on here, where we gained about 3.7%. But we used the 4090 for our tests because this is our standard CPU review GPU, and given the general proximity, we still get most of the scaling here while being able to remain consistent for our future CPU test suite.

The 13600K and down have lost some framerate from the average, but overall, we were CPU-bound before and we remain CPU-bound now for those CPUs.

Compared to other modern titles, we’re definitely running at a relatively low framerate for 1080p and no ray tracing. This game is heavy and there probably is a lot of room for optimization both at the driver level and the game or engine levels -- especially since the engine remains a Frankensteined Bethesda monster.

When we did a quick validation test at the beginning of this work, we saw that the 7900 XTX and 4090 were within about 3-4% of each other even at a ridiculous 720p/low. This represents to us that, for purposes of selecting a GPU for a CPU-bound specific set of tests, either is fine. 720p/low is an incredibly low GPU load, obviously, and yet we were at the same framerate. By traditional understanding, this would tell us that the GPUs cannot differentiate themselves because the CPU is dictating the performance ceiling -- that’s useful here, since this is a CPU benchmark. We ultimately stuck with the 4090 because that’s what we use in our standardized CPU reviews.

Starfield CPU Conclusions

Wrapping things up, we learned that at the very top end, you can definitely be clock-bound, which indicates that there are benefits to overclocking.

Starfield, in general, is very GPU heavy. At higher settings like 1440p and above or if you’re using high to ultra settings, you will more likely be GPU bound, but in situations where you are more CPU limited, say if you’re using an R7 2700, 3700X, 12400, 13400, or something like a 13100F, you have some options. In cases where you have an unlocked CPU like the older Ryzen stuff especially, we think if you haven’t yet, it’s a good time to explore overclocking because you can actually get some clock scaling benefit here.

For people considering new purchases, there are a couple of takeaways. We saw on modern architectures that there’s some core count scaling between six core and eight core CPUs. It’s not huge but it exists so there’s some benefit there, particularly on AMD. On Intel, using a 13700K or 13900K, you’re more likely to start bouncing off of a GPU limit because you’re realistically not going to be playing at 1080p low settings, since we imagine you’ll try to push the graphics a little bit more on your system; otherwise your rig would be wildly imbalanced in terms of components. If you intend to play at something like 1080p high or 1440p with reasonable settings, then the 13700K and 13900K will be very similar to each other. The 13600K is also pretty close to them as well in those more graphics-intensive scenarios.

We benchmark and breakdown which GPUs are best for Starfield

The Highlights

• Starfield is the long-awaited space RPG from famed developer Bethesda
• The game is taxing on both GPUs and CPUs
• Being an “AMD-exclusive” launch, AMD’s GPUs perform competitively against NVIDIA’s
• Original MSRP: $70
• Release Date: September 6, 2023

Today we’re testing Starfield, Bethesda’s new “Skyrim in Space” RPG. We have some cool research tests to talk about performance scaling in the game and a good amount of benchmarks -- at least for something turned around inside of about 16 hours -- for a day-one test. We ran about 16 cards through the benches, ranging from the 10 series to 40 series on NVIDIA and the RX 5000 series to RX 7000 series on AMD. This was a HUGE haul to get the data all done in time for people beginning to plan builds, and keep in mind that we’re actively adding more to our Starfield content. We’ll have some follow-up pieces. But a couple of things: This is an AMD exclusive launch title. Intel seemingly didn’t get any kind of access to build its Arc drivers, and likewise, NVIDIA’s “game-ready” driver appears to be the same (or mostly the same) as its driver prior to this one. It’s likely that there will be further game and driver updates improving performance at this point, so if you’re checking these benchmarks in a year, the scaling may move -- especially for NVIDIA. And Intel. Because, in the latter case, you can’t divide by 0.

Credits

Test Lead, Host, Writing

Steve Burke

Testing, Video Editing

Mike Gaglione

Testing

Jeremy Clayton
Patrick Lathan

Video Production

Vitalii Makhnovets

Writing, Web Editing

Jimmy Thang

Starfield Graphics Card Test Setup & Prep

These used the latest NVIDIA and AMD day-one drivers. Intel isn’t ready yet and the game didn’t launch on Arc, but the company says it’ll be ready for the true launch date of September 6.

There are a lot of ways to test games and there’s a ton of room for differing results based on how the test is handled. Today, we’ll be walking you through some of our research process for determining our methods, then we’ll go over the data we got with those methods. Remember that choices such as disabling FSR, Vsync, and Variable Rate Shading (and dynamic resolution) will impact results compared to tests that might leave them on, so you should look at the numbers largely against themselves and avoid cross-comparing if there are unknown variables in the settings.

Researching Starfield's Graphics Performance

We’ll start with our research for Starfield performance. The research process is an important period where we spend a few hours exploring various types of gameplay and environments to try and get an overall picture for performance, which helps us choose a location for testing. Our goals for finding a test location are to choose something that is closer to a “worst case” while still being a common gameplay scenario.

For this process, we captured the frametimes for the first couple hours of play and logged them. This included the tutorial cave, the initial outdoors location on the moon or asteroid or whatever it was, the ship, take-off, space flight, combat on foot and combat in space, Kreet and its indoors research lab, and New Atlantis City. Games are highly variable dependent on location, and choosing a location has all the impact on the results that sets us up for long-term benchmarking.

Starfield Screenshots Gallery

Below are some screenshots from our research areas. You can check the video embed above for more individual detail.

GN 2022-2023 GPU Test Bench Specs

This research was captured on a 4060 Ti at 1440p/high. We want to emphasize that the settings and card are basically totally irrelevant for the research other than one important thing: We need to make sure we’re GPU-bound so that we can determine an area that’ll show scaling. For this, we choose settings that should typically put us closer to 50-60FPS so we still have range above and below the research results.

Starfield Graphics Performance Testing

Here’s the chart. We have FSR, upscaling, dynamic resolution, and variable rate shading all disabled here.

The 4060 Ti at 1440p/high held in the 70s in a few locations -- notably, inside one of the areas of the early cave and inside the lab on Kreet. We observed in the 40s FPS AVG for initial conversations where high poly detail is loaded-in. Outdoors roaming ranged, but we saw mostly in the 40s. Space combat and space flight had us typically around 50FPS, +/- a bit. Take-off had a severe frametime spike a couple of times, but as this is moved to a hands-off animation, that seems less relevant.

We also captured two sets of 10 minutes of gameplay in New Atlantis City. This is useful to give us a fuller picture of averaged frames across large parts of the city, with loading screens removed from the numbers. These should also be considered fairly representative to play.

Sparing you all the details of each of these numbers individually, you’ll notice two important ones at the bottom: ALL GAMEPLAY AVERAGE is the average FPS and 1% of each number above it, producing a common framerate of 53 across all scenarios, including averaging for the tests in the 70s. Once we had this number, we chose an area of New Atlantis City that was fairly close but leaned a little heavy, that way we have a representative sample of a higher load city scenario. The end result was a 48.6 FPS AVG here. Remember that it’s possible there are areas later in the game that are heavier, but given that we captured a few hours of play and came up with these numbers, we think the test area selected is a safe lower-end representation for high-density areas like cities.

We tested in the Residential District of the city and had a fixed walking path. We did a number of one-off tests in this area, but before we get into the comparative charts, let’s look at some quick settings research.

One-Off Settings Impact

As the next part of our research process, we tested each preset (but with FSR disabled, upscaling off, and variable rate shading off) in the same location, using the same test processes, on the 4060 Ti at 1080p. Again, we’ll get to all the cards -- but we needed this for a rapid understanding.

Here, we found that the RTX 4060 Ti at 1080p held an average framerate of 53FPS at ultra, improving by 17% by dropping to high, now at 61FPS AVG. Cutting that to medium gave us an additional 16% framerate, and cutting to low boosted us to 82.6FPS, or another 16%. Bethesda has remarkably consistent scaling from one preset to the next here, making it seem very intentional how they assigned the settings. It’s about a 10FPS improvement on this particular card for each graphics setting decrease.

FPS over Time (Gameplay Observations)

One final research chart: This isn’t a frametime chart, but rather just an FPS over time chart. We’re plotting the framerate as we played through various parts of the game. This is 34,000 frames of data. It’s about 10 minutes of gameplay. We truncated the chart to 100FPS -- the spikes above that go to over 200FPS and are just when we were in menus, inventory, or loading screens. For the rest, you can see the range was typically 40 to 70, with most of the numbers clustering around 50-60 FPS AVG on this device and with these settings. The game has some plunges, but is otherwise relatively consistent.

Standard Deviation

Finally, as we get into our first and densest chart, we’ll look at run-to-run consistency with standard deviation. This is not an indicator of the GPU quality, but rather the standard deviation for that card’s test passes. We have a minimum of 4 passes, sometimes more. Each pass is an average of thousands of frames of data.

Generally speaking, we were within about 1FPS standard deviation run-to-run. Lows are always wider here since there’s less data to work with by their nature. Averages are extremely consistent run-to-run, making this, overall, relatively easy to parse.

Starfield Graphics Card Benchmarks

Starfield 1080p High GPU Comparison

Up first, our 1080p/high chart. In this one, the RTX 4090, RX 7900 XTX, and RTX 4080 are all bottlenecked. We can ignore these results as they didn’t have enough scaling room -- we’d need a higher-end CPU or an area of the game with less CPU load.

Shifting attention to unbound comparisons, the 6800 XT remains a strong modern option and sits atop the 4070, with the 6700 XT technically leading the 4060 Ti, but being functionally equivalent. The RTX 3080 remains completely viable here as well. The 3060 Ti and 4060 Ti have more of a gap here than they have at higher resolutions, but that’s behavior we already saw in our 4060 Ti review -- they tend to converge, and the last-gen option can even surpass the 4060 Ti in some games at higher resolutions.

The RX 7600 and RTX 4060 are roughly tied in average framerate, with the 7600 having a technical lead -- and a price advantage right now.

As for older hardware, like the 1070 and 2060, we’d have to turn to lower settings.

Starfield 1080p Medium GPU Comparison

We didn’t test many cards at 1080p/medium, but here are the ones we did. The movement in absolute FPS isn’t much. The 1070 and 2060 are benefited, but not enough to move the needle without other settings reductions. The RX 7600 overall does well relative to the rest of this group, especially with its newer sub-$250 price we’ve been seeing around.

Starfield 1080p Low GPU Comparison

If you're wondering whether your lower-end video card can play Starfield and handle it, here are some low settings tests.

We only ran 2 cards at 1080p/Low. Here are the results. The 4060 gained about 10FPS against its test at medium settings, with the 2060 gaining a little less than that.

Starfield 1440p High GPU Comparison

Moving to 1440p and high settings, the top remains bottlenecked -- although it’s reducing -- and the equivalent FPS between two resolutions for these top 3 cards indicates that bottleneck. The more relevant comparisons happen below the 95+ range.

The 4070 and 3080 are about equal here, with the 4060 Ti and 6700 XT also close in rank. None of the lows on this chart jump out to us as particularly bad. In general, they’re not keeping pace with the average as well as we’d like (and had seen in other tests), but they’re consistently low across all devices.

Starfield 4K High GPU Comparison

We’re on to 4K/high next. We didn’t do as many tests on this as the prior settings due to the intensity of the configuration.

The RTX 4090 leads the charts by a technicality, although in reality, it’s tied with the 7900 XTX. They’re within run-to-run variance of each other for average, 1%, and 0.1% lows. The 7900 XT manages 87% of the performance of the 7900 XTX, at 64FPS AVG. The RTX 4080 is just behind that, at 58FPS AVG. That means the gap between the 4080 and 4090 is 30% here. That’s about the same as we’ve seen in other games. The 3080 is also near its usual distance from the 4090, although a little higher than typically: It allows the 4090 a little over an 80% lead. 

As for all these cards under the RTX 4080, remember that we’re (1) at 4K, and (2) establishing scaling in a relative sense. You could reduce settings or add upscaling and increase framerate to good playability on something like the 6800 XT or 3080 -- and with FSR -- even lower than that. But for testing purposes, we’re showing the ranking of the cards relative to each other.

The 1080 Ti was once among the few early cards that could really handle 4K games, but for this one, it’s just not able to do it without some external assistance.

Starfield 4K Ultra Settings GPU Benchmarks

4K ultra is pretty simple. We don’t have many cards that can run this well, so it’s a limited list. The RTX 4090 ran 4K/ultra without upscaling and in the city at 68 FPS AVG, with lows paced roughly proportionally behind. That has the 7900 XTX and 4090 about tied, with no meaningful difference between them in any of the 3 reported metrics.

The 7900 XT allows the 7900 XTX a lead of 14%, while the XT non-second-X leads the RTX 4080 by about 14%. The 4080 then leads the 6800 XT by 26%.

Even at the 6800 XT level, you could still run at 4K/ultra with some use of FSR and upscaling. That’s an option here. It’s not a particularly great experience at 40FPS, but dropping settings or adding FSR would get it the rest of the way there.

Conclusion: The Best Gaming GPUs for Starfield

Starfield is a demanding game, both from a GPU and CPU perspective. On the graphics side, AMD’s performance has been very competitive here in some cases. That’s not surprising given the “exclusive” partnership. Intel stated publicly that it’ll have drivers ready next week for the public launch, so we’ll have to revisit then. NVIDIA likely will also have driver updates.

We plan on retesting many of these cards on the public launch to see how things change.

As for the game itself, our higher-end cards were bottlenecked on the lower resolutions, but outside of the top cut of cards, we noticed older hardware struggling. This is an instance where you will want FSR -- unfortunately not version 3 -- for any help you can get on hardware predating the last generation or two. 

Let's look into which video cards are best for Starfield at different price points and budgets:

Best $200-$300 graphics cards for Starfield

For something $200-$300 for Starfield, the AMD RX 7600 is a strong performer here. The RTX 4060 would be the NVIDIA alternative if you'd prefer NVIDIA features for other games; however, in our Starfield testing, the RX 7600 leads the 4060 by 8.4% and costs less.

Best $300-$400 graphics cards for Starfield

We’re targeting a native 60FPS as our north star (without any upscaling – check out our Starfield Graphics Optimization Guide for tips on that end) while taking into account price. Here, we recommend the RX 6700 XT. Our XFX RX 6700 XT card was able to garner 63.8 AVG FPS on the game’s high preset at 1080p. The most affordable variant we found online currently retails for $330. If you’re looking for an NVIDIA card because you prefer that ecosystem, then the NVIDIA RTX 4060 Ti is unfortunately the closest competitor -- but it has many of its own downsides (most of which are related to value). We generally recommend avoiding the 4060 Ti, but especially the 16GB variant. It won't gain you anything meaningful, as the card is too constrained on its core to benefit from the extra memory, and the price hike is huge by comparison. The $380 pricing of the 4060 Ti makes it untenable against alternatives here. If you're OK with used hardware, you should seriously consider an RTX 3080 or RX 6800 XT -- although those push up into the next price category. Assuming you want NVIDIA's solutions or might want to play NVIDIA-favored titles, like Cyberpunk 2077: Phantom Liberty, the RTX 4070 or RTX 4060 are more competitive options.

$500-$600 graphics card for Starfield

If you’re looking to game at 1440p, you'll most likely have to pony-up between $500-$600. The card that makes the most sense in this price range is the RX 6800 XT. Our Sapphire card managed to achieve a 71.2 AVG FPS on the high preset. Unfortunately, 6800 XT cards are becoming rare -- although there are still some well-priced RX 6800 non-XT cards on Newegg. At $500, the 6800 XT model slightly outperformed the NVIDIA RTX 4070 12GB for $50 less. The 4070 performed on par with our EVGA RTX 3080, so those would be a good second-hand option.  

$800+ graphics card for Starfield

If you’re looking to game at native 4K, options are limited without FSR or DLSS. If you're open to either of those technologies, well, technically, it's not actually 4K anymore -- but they'd expand your options to cheaper cards.

Here, our recommendation for native is the AMD RX 7900 XT. It garnered a 64.3 FPS AVG on the high preset. At $800, the 7900 XT outperforms its closest rival, the RTX 4080. The AMD card was faster than it by 10.7%. It also costs $400 less at the time of writing. Even at 4K ultra, the card performs well, netting a 58.1 AVG. If you did want above 60FPS performance at 4K ultra, you’ll want to turn to either the RX 7900 XTX or the RTX 4090. Those cards got 66AVG FPS and 68.4 AVG FPS, respectively. The RX 7900 XTX is definitely the better value here at $950 compared to the 4090's steeper $1,730 price tag.