Reproducible field report

DOOM: The Dark Ages — Vulkan Streamline / Reflex Limiter / Path Tracing Reproduction

Tested 2026-08-29 • RTX 5090 • NVIDIA driver 591.59 • Ryzen 7 9800X3D • 2560×1440 @ 144 Hz • Vulkan

Provenance. This page was assembled by ChatGPT. All testing, screenshots, CVar discovery, repeated A/B comparisons, findings, and conclusions documented here are Dresk's.

Why this investigation started. There are two separate questions. First: how can DOOM: The Dark Ages be held slightly below a 144 Hz VRR ceiling so it does not repeatedly enter the higher-latency VSync ceiling? Many shipped Reflex / Frame Generation titles do this automatically, but DOOM: The Dark Ages exposes no normal frame-rate limiter in its video menu. The game does, however, contain a hidden Streamline/Reflex limiter: r_streamlineReflexMinFrameTimeUs.

The second problem. That hidden limiter works on the normal rendering path, including with 2× DLSS Frame Generation. But when Path Tracing / Ray Reconstruction is active and FG is actually presenting generated frames, the limiter stops governing final output even though the CVar remains set. In menus, where FG reports Presented 1x, the limiter immediately starts working again.

Path Tracing / Ray Reconstruction Frame Generation VSync Frame-limit CVar
Goal 1: sub-refresh pacing Key CVar NVIDIA integration notes State matrix Receipts Goal 2: Path Tracing failure Minimal reproduction

Goal 1: keep output below the VRR ceiling

On a 144 Hz G-SYNC/VRR display, the practical target is roughly 138 FPS rather than repeatedly touching 144 FPS and entering the VSync ceiling. This is familiar behavior in many shipped Reflex + Frame Generation titles: the presentation path stays slightly below maximum refresh, preserving VRR behavior and avoiding the additional latency associated with hitting the VSync ceiling.

DOOM: The Dark Ages does not expose a normal frame-rate limiter in its video menu. The engine does expose one through Streamline/Reflex.

The key CVar

r_streamlineReflexMinFrameTimeUs 7250

1,000,000 / 7250 = 137.93 FPS

The engine itself describes the CVar as the minimum frame time sent to Reflex, in microseconds. Empirically, while Streamline is active, 7250 µs behaves as a real pacing target. It still works when visible Reflex Low Latency is set to Off. If Streamline is disabled entirely, the same CVar becomes inert.

What NVIDIA documents developers actually doing

NVIDIA's Streamline Reflex programming guide treats the Frame Rate Limiter as a separate Reflex-plugin sub-feature, controlled by sl::ReflexOptions::frameLimitUs. The same options structure independently controls Reflex Low Latency mode.

At integration time, the developer sets the desired options with slReflexSetOptions(), then calls slReflexSleep() at the point in the application's frame loop where it should sleep for pacing / latency behavior. NVIDIA specifically says slReflexSleep() should continue to be called even when Reflex Low Latency mode itself is Off.

For DLSS Frame Generation, NVIDIA's Streamline guide also requires the host application to integrate Streamline Reflex and provide correctly matched frame markers.

What the engine says

r_streamlineEnabled "is":"2" default:"2"
0 = Disable Streamline
1 = Enable Streamline
2 = Enable Streamline using slSetTagForFrame() API

r_streamlineEnabled can only be set on the command line
LOG: Disabling Vsync because it is not supported while FG is active.

These statements establish two useful boundaries visible from the game itself: Streamline residency is effectively a process-level integration choice, and the engine knowingly disables VSync when Frame Generation becomes active.

Observed state matrix

PathVSyncFGPT / RRCVarObserved output
Streamline activeOffOffOff0~190+ FPS
Streamline activeOnOffOff0~144 FPS
Streamline activeForced off by FG2x activeOff0~330+ FPS
Streamline activeOff2x activeOff7250 µs~69 real → ~138 final
Streamline activeOff2x activePT + NRR7250 µs~110–114 real → ~220–228 final
Streamline active, menuOff2x configured / Presented 1xPT + NRR7250 µs~138 FPS
Streamline active, menuOffOffPT + NRR7250 µs~138 FPS
Streamline disabledVariesUnavailableVaries7250 µsLimiter inert

Findings

1. Ordinary Vulkan VSync works when FG is not active.
With Streamline loaded and FG off, VSync off allows roughly 190+ FPS, while VSync on clamps output to the display ceiling.
2. The engine explicitly disables VSync when FG becomes active.
This is logged directly by the engine; it is not inferred from FPS behavior.
3. The hidden Reflex/Streamline limiter solves the original pacing problem.
With normal 2× FG, 7250 µs lowers real rendering to roughly 69–70 FPS and holds final output near 138 FPS. It also functions with visible Reflex Low Latency mode disabled.
4. Streamline must actually be active for the limiter to work.
Disabling Streamline at launch leaves the CVar registered, but the limiter becomes inert.
5. The second bug is specifically the combination of Path Tracing/Ray Reconstruction and actively presented FG.
The CVar remains at 7250, but final output rises to roughly 220–228 FPS. PT without active generated-frame presentation does not reproduce the failure.

Receipts

Click any screenshot to open the original embedded image in a centered modal. Page scrolling is locked until the image is closed. Click the image again, click outside it, or press Esc to return.

Receipt group 1 — Finding the hidden below-refresh limiter

The first receipts establish the normal presentation behavior: VSync with and without FG, Streamline residency, the hidden frame-limit CVar, and the fact that 7250 µs can reproduce the desired ~138 FPS sub-refresh target.

Receipt 1: Baseline: Reflex limiter works with Reflex/ VSync / FG off

Streamline is active. r_swapInterval=0, r_streamlineReflexMode=0, Frame Generation OFF, and r_streamlineReflexMinFrameTimeUs =7250. Engine, Steam overlay, and monitor hardware counter all sit at ~138 FPS. 1,000,000 / 7250 = 137.93 FPS.

Receipt 2: Streamline can be disabled only at process launch

The engine reports r_streamlineEnabled default 2, where 2 uses the slSetTagForFrame() API. Setting it to 0 is command-line only.

Receipt 3: Streamline disabled exposes the internal DLSS-sized viewport

With Streamline removed while the game is still configured around DLSS Quality render dimensions, the 3D viewport is visibly confined to roughly 1707x960 inside the 2560x1440 output, while the HUD remains full-resolution. This exposes the separation between internal render resolution and final composition.

Receipt 4: Vendor and graphics DLLs loaded by the process

Process Explorer module list captured with Streamline disabled. The process still contains multiple graphics/vendor SDK components. Loading a DLL does not prove its rendering path is active, but it documents the modern renderer's dependency surface.

Receipt 5: Streamline on, FG off, in-game VSync off

With native Frame Generation off and the Reflex minimum frame time at zero, VSync off allows the game to run around 190+ FPS.

Receipt 6: Streamline on, FG off, in-game VSync on

Same basic path, but ordinary in-game VSync now clamps the output to roughly the 144 Hz display ceiling. This establishes that basic Vulkan VSync works when FG is not active.

Receipt 7: FG active: engine explicitly disables VSync

With DLSS Frame Generation active, the console logs: 'Disabling Vsync because it is not supported while FG is active.' Output rises to roughly 330+ FPS when no Reflex frame-limit value is supplied.

Receipt 8: FG active + 7250 us limiter: final output becomes ~138

With 2x FG active and r_streamlineReflexMinFrameTimeUs =7250, real rendering falls to roughly 69-70 FPS and final presented output is ~138 FPS. The value behaves as an FG -aware final-output pacing target on this path.

Receipt 9: Menu state: FG configured 2x, Presented 1x, limiter still applies

In the menu, FG remains configured as DLSS 2x but reports Presented 1x. The 7250 us limiter still holds the menu to ~138 FPS. This is consistent with FG interpolation being suspended while resources/configuration remain resident.

Receipt group 2 — Path Tracing breaks the limiter only while FG is actively presenting

From this point forward, the test changes from “does the limiter work?” to “why does the limiter stop working when Path Tracing / Ray Reconstruction is enabled?” The receipts isolate the failure to PT/RR plus actively presented Frame Generation. The same limiter works again in menus where FG becomes Presented 1x, and it also works with PT still active when FG is disabled.

Receipt 10: Path Tracing OFF: 7250 us limiter behaves normally

With Path Tracing off, the limiter again produces ~138 FPS. Right-side metrics show PT off and DLSS SR Quality.

Receipt 11: Path Tracing + Ray Reconstruction + active FG : limiter stops governing final output

Path Tracing is enabled; the right-side metric reports PT : (NRR), consistent with NVIDIA Ray Reconstruction . r_streamlineReflexMinFrameTimeUs still reads 7250, yet real rendering is roughly 110-114 FPS and final FG output is roughly 220-228 FPS. The CVar value survives, but its final-output pacing effect does not.

Receipt 12: PT + FG configured, menu Presented 1x: limiter works again

With Path Tracing still active, entering the menu suspends actual frame generation (Presented 1x). The same limiter immediately returns to ~138 FPS.

Receipt 13: PT active + FG disabled in menu: limiter also works

Path Tracing remains active while FG is disabled; the 7250 us limiter continues to cap at ~138 FPS. The failure therefore requires the combination of Path Tracing / Ray Reconstruction and actively presented generated frames.

Interpretation

The screenshots prove the observable states and frame-rate behavior. They do not expose idTech or Streamline call graphs. The interpretation below is intentionally conservative.

On the ordinary 2× DLSS FG path, the Streamline/Reflex pacing system appears to treat 7250 µs as a final-output target: host rendering drops to roughly 69–70 FPS so generated presentation lands near 138 FPS.

With Path Tracing + Ray Reconstruction and actively presented FG, that coordination changes. The game instead renders around 110–114 real FPS and FG doubles it to roughly 220–228 FPS despite the CVar still reporting 7250.

The menu state is the strongest discriminator. As soon as generated-frame presentation is suspended to Presented 1x, the limiter starts working again without disabling PT. That places the defect at the intersection of the PT/RR path and active FG presentation, not in PT alone and not in storage of the CVar.

No claim is made here about AMD hardware behavior. These tests establish behavior on an RTX 5090 only.

Minimal reproduction

Display: 2560x1440 @ 144 Hz VRR
GPU: RTX 5090
Driver: 591.59
Renderer: Vulkan

Set:
  r_streamlineReflexMinFrameTimeUs 7250

1) Path Tracing OFF, DLSS FG 2x active:
   ~69-70 real FPS -> ~138 final FPS
   limiter behaves as expected.

2) Path Tracing + Ray Reconstruction ON,
   DLSS FG 2x actively presented:
   CVar still reports 7250
   ~110-114 real FPS -> ~220-228 final FPS
   limiter no longer governs final output.

3) Keep PT/RR ON and enter a full-screen menu:
   FG remains configured as 2x but reports Presented 1x
   limiter immediately returns to ~138 FPS.

4) Keep PT/RR ON and disable FG:
   limiter remains ~138 FPS.

Failure condition:
  PT/RR + actively presented DLSS Frame Generation.

Observed facts are separated from implementation inference. The screenshots are the primary evidence.