Intro
There’s a moment that keeps repeating itself.
You launch Cyberpunk 2077, the screen fades in, neon bleeds into puddles, and for a second, everything feels perfect. Then you move the camera—and something breaks. Not visually, not exactly. It’s the feeling. The weight. The smoothness.
You glance at the counter.
28 FPS.
And that’s where this story begins.
The Illusion
At first, I did what everyone does. I tweaked the isettings. Lowered shadows. Disabled ray tracing. Tried to convince myself that native resolution was somehow “purer,” more honest.
But then I enabled DLSS.
Nothing dramatic happened. No fireworks. Just a quiet shift. The city felt… stable. Motion smoothed out. The image held together even when I turned quickly, even when lights streaked across the screen.
Later, I tried FSR. Not out of necessity, but curiosity.
And that’s when I realized something uncomfortable:
I couldn’t fully trust my eyes anymore.
DLSS seemed sharper in motion, especially around thin objects—wires, fences, UI edges. FSR, particularly the newer versions, held up surprisingly well, but every now and then, during a fast pan, something would smear ever so slightly. Not enough to break immersion. Just enough to notice.
But noticing isn’t measuring.
And that distinction matters.
The Turning Point
At some point, I stopped asking “which looks better?” and started asking:
“Can I prove it?”
Because human perception is unreliable. It adapts. It lies. It fills in gaps.
So instead of switching settings manually, trying to remember what I saw five minutes ago, I decided to remove myself from the equation entirely.
No more guessing.
Let the system run the same scene. The same camera path. The same workload.
Again and again.
That’s when the idea of automation stopped being “nice to have” and became essential.
Building the Experiment
On Linux, running through Steam and Proton, things are already one layer removed from native reality. Vulkan translates DirectX, Proton emulates Windows behavior, and somewhere in that stack sits DLSS or FSR, trying to reconstruct an image that was never fully rendered in the first place.
It sounds fragile.
But it isn’t.
In fact, it’s predictable—if you control it properly.
So instead of launching the game by hand, I wrote a small script. Nothing fancy. Just enough to start Cyberpunk 2077 in benchmark mode, switch between upscaling methods, and log everything it reports.
#!/usr/bin/env bash
GAME_ID=203140
STEAM_PATH="${HOME}/.steam/steam"
run_bench() {
local mode=$1
local res=$2
local log=$3
echo "=== Running $mode (internal $res) ===" | tee -a "$log"
STEAM_RUNTIME=1 \
PROTON_USE_DXVK=1 \
PROTON_ENABLE_NVAPI=1 \
PROTON_LOG=1 \
"$STEAM_PATH"/steamapps/common/Proton\ GE\ 9.0/proton run \
"$STEAM_PATH"/steamapps/common/"Cyberpunk 2077"/bin/x64/Cyberpunk2077.exe \
-benchmark -resolution $res -upscale $mode \
>>"$log" 2>&1
sleep 5
}
LOGFILE="${HOME}/cyberpunk_dlss_fsr_bench.txt"
echo "Cyberpunk Benchmark – $(date)" >"$LOGFILE"
run_bench "dlss_quality" "2560x1440" "$LOGFILE"
run_bench "dlss_performance" "1920x1080" "$LOGFILE"
run_bench "fsr_quality" "2560x1440" "$LOGFILE"
run_bench "fsr_performance" "1920x1080" "$LOGFILE"
echo "Done. Results saved to $LOGFILE"
It doesn’t look like much. But this little script does something important: it removes inconsistency.
No human input. No bias. Just repeated, controlled runs.
What the Machine Reveals
When you let the benchmark run like this—quietly, repeatedly—you start to see patterns.
Native 4K, as expected, struggles. It looks pristine, but the performance cost is obvious. The GPU works harder, draws more power, and delivers less responsiveness.
Then DLSS steps in.
Not as a compromise, but almost as a correction.
At “Quality” mode, it reconstructs the image from a lower internal resolution, yet somehow manages to preserve the fine detail that you would expect to lose. Fabric textures, subtle scratches, and reflections—they remain intact, sometimes even cleaner due to temporal stability.
FSR tells a slightly different story.
It doesn’t rely on dedicated hardware like Tensor Cores. It’s more democratic in that sense—available across GPUs. And in its newer iterations, especially FSR 2.x, it gets remarkably close to DLSS in still scenes.
But motion is where the difference quietly reappears.
During fast camera movement, DLSS tends to hold edges more consistently. FSR occasionally introduces a faint softness or a brief smear when motion vectors aren’t perfect. Not always. Not dramatically. But enough that, when you compare logs and revisit footage, you begin to understand the trade-offs.
Enabling the Magic
Getting all of this working on Linux is surprisingly uneventful—once you know what matters.
Inside Steam, you ensure the game runs with a recent Proton version. Ideally, something like Proton GE, which exposes NVAPI properly so DLSS can function.
Inside Cyberpunk 2077, the options appear as they would on Windows. DLSS for NVIDIA hardware, FSR for everything else.
Sometimes DLSS shows up grayed out. That usually means the driver isn’t exposing Tensor Core capabilities correctly. A quick check with nvidia-smi tends to confirm that suspicion.
Once it’s enabled, though, it just works.
Which, on Linux, still feels slightly magical.
Where Things Break
Not everything is perfect.
Sometimes the benchmark crashes after a run. Sometimes Proton behaves differently between versions. Occasionally, a mod or shader interferes with motion vectors, and suddenly DLSS starts ghosting in ways it shouldn’t.
These aren’t failures of the technology so much as reminders of the layers involved.
You’re not just benchmarking a game.
You’re benchmarking:
- the game
- the driver
- Proton
- Vulkan translation
- and the upscaling algorithm itself
All at once.
And yet, despite all that complexity, the results are consistent enough to trust—if you automate them.
The Realization
After running the script a dozen times, after scrolling through logs filled with frame times and GPU utilization, something shifts.
You stop thinking in terms of “DLSS vs FSR.”
You start thinking in terms of:
- stability
- reconstruction quality
- motion behavior
- and performance per watt
And more importantly, you realize that the “best” setting isn’t universal.
It depends on what you value.
If you want the cleanest possible image during slow, cinematic movement—DLSS Quality feels almost indistinguishable from native.
If you want responsiveness, high frame rates, something that feels immediate—DLSS Performance or FSR Balanced start to make more sense.
And if you’re not on RTX hardware at all, FSR becomes not a fallback, but a perfectly viable solution.
Closing Thoughts
This part of the journey wasn’t about discovering a winner.
It was about building a way to measure the difference without guessing.
Automation changes the relationship you have with graphics settings. It turns subjective impressions into something repeatable, something you can revisit, compare, and refine.
And somewhere in that process, Cyberpunk 2077 stops being just a game.
It becomes a controlled environment. A testbed. A way to understand how modern rendering actually works—layer by layer, frame by frame.
In the next part, we can take this even further—parsing the logs, visualizing the data, and turning raw numbers into something you can actually see.
Because once you start measuring performance…
You inevitably want to see the story the data is telling.
- DLSS‑Quality vs Native‑Quality:
- Texture Detail: DLSS retains more subtle fabric weave and metal scratches.
- Edge Sharpness: FSR’s CAS sharpening is slightly less precise on thin geometry (e.g., fence wires).
- Temporal Stability: DLSS shows fewer “ghosting” artifacts during rapid camera pans; FSR 2.2 mitigates most ghosting but can occasionally produce a “smear” if motion vectors are noisy.
A Small Detour Before You Go
If you’ve made it this far, you’ve probably already felt it—that quiet shift from playing to understanding. At some point, tweaking settings stops being enough, and you start wanting something more reliable. Something repeatable. Something you don’t have to second-guess every time you relaunch the game.
That’s exactly why I ended up turning this idea into a working project.
The script you saw in this post is just the surface. Behind it sits a more complete, reusable setup that automates the entire benchmarking process for Cyberpunk 2077 on Linux—handling multiple runs, logging, and making it easier to compare DLSS and FSR in a consistent way.
If you’d like to skip the trial-and-error phase and jump straight into something that’s already structured and tested, you’re very welcome to explore it.
You can find my work here:
👉 GitHub profile: https://github.com/dolpa
And the repository itself:
👉 Cyberpunk 2077 automated benchmark: https://github.com/dolpa/dolpa-gaming-on-linux/tree/main/games/cyberpunk%202077
Inside, you’ll find a cleaner version of the script, along with improvements that naturally came out of repeated testing—small adjustments, edge-case fixes, and a structure that makes it easier to expand beyond a single game.
If you decide to try it, treat it the same way this whole post was written: not as a rigid tool, but as something you can adapt. Change the modes. Add new variables. Break it, fix it, make it yours.
Because in the end, this isn’t really about one script—or even one game.
It’s about building a workflow where you no longer have to guess what your system is doing.
And once you reach that point, it’s surprisingly hard to go back.