Graphics presets and upscalers have no measurable effect on VRAM usage or GPU load (RTX 2080 Super)

[dreamy jay]

System Specs:

• GPU: NVIDIA RTX 2080 Super (8 GB VRAM)
• CPU: AMD Ryzen 9 5900X
• RAM: 64 GB
• OS: Nobara Linux 43 (2026-04-19 release), fully updated
• Kernel: 7.0.1-200.nobara.fc43.x86_64
• NVIDIA Driver (Linux host): 595.58.03 (proprietary)
• Proton Version: GE-Proton10-34 (installed as "Proton-GE Latest")
• Engine / Renderer: Unreal Engine 5.6.1-0+UE5, D3D12 (SM6), translated via DXVK/VKD3D-Proton
• Launcher: Launched via Steam with GameMode (gamemoderun) enabled
• Game Build ID: 22851825 (Steam appid 3041230, Windrose-Win64-Shipping)

Summary:
On my setup, neither changing the graphics preset (Epic / High / Medium) nor enabling any of the available upscalers (TSR, DLSS, FSR on Performance) produces a measurable effect on VRAM usage or GPU load. The game consistently saturates the 8 GB VRAM on my RTX 2080 Super regardless of settings. After extended play, performance degrades and the game eventually crashes. I cannot speak for native Windows behavior — this report only describes what I observe in my environment.

Reproduction Steps (most reliable trigger):

1. Load into a save with a modestly sized base (roughly 3 small buildings, little to no geometry overlap).
2. Fast travel between Tortuga and the base, back and forth, a few times.
3. VRAM fills up quickly and the issue becomes immediately noticeable — stutters within minutes.
4. Changing graphics preset between Epic, High, and Medium during this scenario produces no measurable difference in VRAM usage or GPU load.
5. Enabling TSR, DLSS, or FSR on Performance also produces no measurable difference.
6. Returning to the main menu (without closing the game) sometimes temporarily alleviates the issue, but a full game restart is usually required to reset VRAM usage.

Note on initial upscaler state: On the captured session described below, the in-game settings UI reported FSR active at 70% screen percentage from game start. However, the engine log at boot shows r.FidelityFX.FSR.Enabled:0 (the documented boot-time default). This suggests either the UI does not reflect the actual engine state, or FSR is being applied via a different code path (e.g. screen-percentage scaling rather than the FSR enable CVar). Either way, VRAM still saturated to ~7.8 GB during gameplay.

Expected Behavior:

• Lowering the preset from Epic to Medium should noticeably reduce VRAM usage (texture resolution, shadow map size, etc.).
• Enabling an upscaler on Performance should lower the internal render resolution and reduce both GPU load and VRAM footprint.
• Fast travel between zones should not progressively accumulate VRAM usage to the point of saturation.

Actual Behavior:

• VRAM usage remains effectively identical across all three presets.
• GPU load stays at 93–98% regardless of preset or upscaler setting.
• Enabling DLSS / FSR / TSR at Performance produces no visible performance change and no VRAM reduction.
• Repeated fast travel between Tortuga and base accumulates VRAM usage until saturation.
• Eventually results in heavy stuttering and crashes. A full game restart resolves the issue temporarily. "Back to main menu" occasionally helps but is not reliable.

Additional Notes:

• System is fully up to date: Nobara 43 with latest kernel, latest NVIDIA proprietary driver, latest Proton GE build.
• Tested at identical in-game locations after full restarts between setting changes, so this is not an asset-caching issue on my end.
• This may suggest a VRAM leak or a missing resource cleanup during zone transitions, combined with preset/upscaler settings not properly affecting the render pipeline.
• Happy to provide logs, nvidia-smi output, MangoHud captures, or a video demonstrating the fast-travel repro if helpful.
  Engine log confirms root cause: Texture Pool = 4411 MB (Epic) vs 4348 MB (Medium) — only 63 MB / 1.4% difference. r.Streaming.LimitPoolSizeToVRAM=1 ties pool to VRAM, not to preset.

[glacial palm]

FYI upscalers do not reduce VRAM usage, they themselves have a VRAM overhead.

[dreamy jay]

Valid point on the VRAM overhead, but that's not the main claim, the claim is that neither GPU load nor render time changes. DLSS Performance renders internally at 540p instead of native 1080p (75% fewer pixels to shade), yet nvidia-smi shows GPU utilization staying at 88-96% before and after the toggle. That part is independent of the VRAM overhead discussion.

[glacial palm]

Which brings us to the next point:

OS: Nobara Linux 43
Is this reproducible on Windows OS ?

[dreamy jay]

As stated in the summary: "I cannot speak for native Windows behavior — this report only describes what I observe in my environment."
That said, the root cause I documented is not platform-specific. It lives in the game's Scalability.ini: the [TextureQuality@X] sections don't override r.Streaming.PoolSize, so with r.Streaming.LimitPoolSizeToVRAM=1 the texture pool stays tied to available VRAM regardless of preset. That config behavior runs before any RHI translation (D3D12 on Windows, D3D12→VKD3D on Linux), so a Windows user with the same 8 GB card should see an identical ~4400 MB texture pool and identical lack of preset-level VRAM reduction.
If anyone running native Windows wants to verify, the relevant line is in %LocalAppData%\R5\Saved\Logs\R5.log: LogRHI: Texture pool is XXXX MB (70% of YYYY MB). Would be genuinely useful to have that data point.

[glossy violet]

Im seeing similar behaviour. Im also on linux running cachyos, im using AMD R7 9800x3d with rx7900xtx. And from what i experienced, fsr does also almost nothing to the frame times.
Tough i have enough rendering power to get 100+ fps, so its fine in my case.

[dreamy jay]

Good to have the confirmation and especially on a completely different GPU stack (AMD instead of NVIDIA, 24 GB instead of 8 GB). That strongly suggests the issue is engine-config-level, not driver or platform.
If you have a moment, could you grep your R5.log for this line?
LogRHI: Texture pool is XXXX MB(70% of YYYY MB)
It's in * %LocalAppData%\R5\Saved\Logs\R5.log * (or the equivalent Proton prefix path). Based on my theory, on a 24 GB card the pool should be around 16-17 GB — i.e. 70% of total VRAM, same formula as my 8 GB card, and equally preset-independent.
That would confirm that r.Streaming.PoolSize is VRAM-scaled instead of preset-scaled across the board.

[glossy violet]

Sorry, to disappoint you, but im currently not at my pc right now. It`ll probably take 4-5 hours for me to be back home again. If i dont forget it, i'll post it later.
I just purchased and started playing 2 days ago and while seeing massive performance drops with torches in my base, i was tinkering a little bit and was confused, that the frametime does not seem to be affected with fsr on.

[dreamy jay]

No rush at all. To be honest, I don't personally need the log value, I can already see the behavior on my own setup.
It would mainly help the devs later when they try to pin down the exact scope, so if you happen to post it when you're back that's great, and if not no stress.
The torch observation is actually another useful data point regardless: torches in UE5 are typically dynamic shadow-casting point lights with their own cube-depth shadow maps in VRAM. Multiple torches in a
confined space add up fast. And your FSR/frametime note matches the same pipeline issue I'm seeing, internal render resolution should drop with FSR Performance, but if frame time doesn't move, something in the pipeline is ignoring the resolution scale.

[glacial palm]

The limit to VRAM pool ensures there's not spill over, which will then dynamically load MIP levels into VRAM pool, so you should never run out of VRAM for the game engine itself, so that may or may not be intended.

Or, do you want the game to purposefully limit VRAM usage for other apps to use or ? 👀

[dreamy jay]

MIP-level streaming addresses texture detail within the pool, that's different from what the preset should be changing. The preset is supposed to affect the overall rendering budget (shadow map resolution, GBuffer precision, post-processing passes, GI quality, render-target scale, and texture pool target). None of those are MIP-streaming.
And „you should never run out of VRAM" isn't matching what I measured: nvidia-smi shows 7767 MiB sustained on an 8 GB card for 2+ minutes while GPU load stayed at 88-96%. Engine didn't crash thanks to
streaming, but frametimes and the rendering pipeline were saturated regardless. That's the documented outcome in the CSV.
The report isn't asking for less VRAM usage for other apps. It's asking for the preset selector in the settings UI to actually change the rendering budget when the user changes it. Right now, Epic → Medium
reduces the texture pool by 63 MB (1.4%) and has no measurable effect on GPU load, that's the behavior the report documents, and it's measurably inconsistent with what a preset selector is supposed to do.

[glossy violet]

Hey, sry for the late reply (was a little busier than i tought after work - lifes not easy sometimes)

LogRHI: Texture pool is 13954 MB (70% of 19935 MB)

As you thought, its the same behaviour with the 70%