[pmwork-personal]

On an RTX 5090 at 5120x2160 the built-in frame generation couldn't follow motion. Its block search covers ±32 px per game frame, so a camera pan's vectors fell to zero and every made frame was a cross-fade of two game frames: smoother counters, same stepping motion. This PR makes those frames with NVIDIA's DLSS Frame Generation through NGX, from the temporal upscaler's own depth and motion. It also fixes two pacing problems that made 3x feel uneven even once the frames were right.

What changed (five commits, each on its own)

1. fix(vk): present 3x and 4x sets ahead too. Frame generation 2x: frames reach the screen 5.7 / 11 ms apart instead of 8.3 (VRR flicker), with cause and a patch #1702's present-ahead (a set's copies go to the GPU together, and only the presents wait for their times) ran for 2x only. At 3x and 4x each made frame's copy still queued behind the game's next frame and reached the screen unevenly. It now runs for any paced set the swapchain can hold, and at 3x/4x the swapchain asks for one spare image per frame (5 and 6 images on NVIDIA).
2. feat(dlss): DLSS-G through NGX (vk_dlss.cpp, beside DLSS on the same NGX session, no Streamline):
   • Inputs. The chain's depth and motion (actor motion included) are copied at its evaluation, with the camera. The scene's projection is now kept beside its view-projection (camera block 0x70).
   • Output. At the present, DLSS-G writes the frame generation row's made frames into the renderer's own set, which the display thread shows and paces as before.
   • Fallback. A set it doesn't make is made by the existing methods, and the log says every 600 presents how many sets DLSS-G made and why it didn't make the rest.
   • Motion units. The motion goes to NGX in render pixels (MvecScale 1), the same as to DLSS. The header's "[-1, 1]" is Streamline's convention. With 1/render size, DLSS-G saw no motion and made cross-fades again; I captured frames to confirm, and it was 0.2/255 off a pure blend at t = 1/3 and 2/3.
   • Exit. The feature is let go with the queue idle.
   • Runtime. nvngx_dlssg.dll is looked for where DLSS's runtime is.
   • Menu. A Frame generation by row: Auto (DLSS-G where it runs, otherwise the built-in one) or Built-in. Both frame generation rows now sit under the Upscaler, as asked in #dev-work. The row changes at once, with no restart. RX_VK_DLSS_FG=0/1 overrides it for a run.
3. fix(vk): V-Sync Auto presents FIFO with DLSS Frame Generation at 2x and up. Auto was mailbox, which on NVIDIA is Fast Sync: below the refresh rate (~135 shown on 165 Hz) frames land on the refresh grid, so evenly timed presents still judder. With DLSS-G making the sets, Auto now asks for FIFO, which a VRR display shows as presented. The built-in frame generation and other GPUs keep Auto as before (from review, item 5). On and Off are unchanged. The swapchain is rebuilt when this changes, as it already is for V-Sync.
4. feat(vk): NVIDIA Reflex with frame generation (added after review). Reflex was off whenever frame generation was on, so its held-back frame added its whole delay (nullifyshot measured +12 to +18 ms at 4x on an RTX 5080). The game's frame calls stay on: the sleep, the simulation markers and render submission. Each set keeps the game frame it was made at, and only that frame is presented with its present id and present markers; made frames get neither. Present ids only go up. Without frame generation nothing changes. On the 5090 at 3x, Reflex's own timings now appear under DLSS-G: simulation start to present end ~41 ms, against ~16 ms with frame generation off (details in the comments).
5. fix(dlss): DLSS-G only where it runs (from review). NGX isn't asked for frame generation's device extensions, or started at a present, on a device without NVIDIA's extensions. V-Sync Auto's FIFO is for DLSS-G only. Frame generation at Off or Auto lets DLSS-G's feature go. A barrier follows a refused frame before the built-in passes write the same images.

How it was tested

• RTX 5090, driver 621.14, Windows 11, 5120x2160 @ 165 Hz with G-SYNC, DLAA, frame generation 3x, Kokiri Forest:
  • DLSS-G made every set in gameplay (600/600 per log window), ~135 fps shown from ~45 game fps.
  • Frames 7–9 ms apart on the display thread. The pacing felt as even as feat(dlss): NVIDIA DLSS Frame Generation through Streamline (Vulkan, manual hooking, Reflex) #1944's Streamline path on the same machine.
  • Clean exits.
• tests/run_all.py (Windows, at 90c4683): 340 passed, 28 skipped, 3 failed. The same 3 also fail on untouched main at this branch's base here:
  • test_recorder_sync's exit case;
  • test_precompile_compute_guard;
  • test_finish_output (a NameError in make_game.py; it passes on current main).
• Updated tests:
  • test_present_ahead.py: 3x/4x with and without enough spare images.
  • test_vsync_row.py: the present-mode choice with DLSS-G and with the built-in frame generation.
  • test_upscaler_rows.py: the new row order.
  • present_source_crop_test.cpp and test_present_semaphores.py: stubs for the new calls.
  • test_recorder_sync.py: knows NGX's DLSS-G create/evaluate calls as direct recordings with their B_DIRECT boundary.

Not tested / known

• Only one GPU (RTX 5090), Windows only.
• Not checked on a fixed-refresh (non-VRR) display, where FIFO would hold frames to the refresh.
• Follow-up: Reflex's "to the GPU's end" reads 243–442 ms under DLSS-G (nullifyshot's measurement). Tagging GPU submits with VkLatencySubmissionPresentIdNV should fix it; I'll do that as its own PR.
• The HUD is drawn into the same picture (no HUD-less input), as with FSR 3.1's interpolation. I didn't see HUD smear at 3x, but I didn't look for it specifically.
• Link's limbs still step a little when jumping; that's the actor motion, not frame generation. feat(vk): DLSS frame generation (NGX), more actor motion for DLSS, FidelityFX FSR 4 fallback (builds with #1833, #1834) #1831/feat: menu, renderer and build plumbing for #1831/#1833; upload hitches; lock diagnostics (builds with #1831, #1833) #1834's single/pair/rigid actor-motion layouts fix his shield and hair here, so I'd suggest those as their own PR. I'll follow up on the arms and feet.
• Relation to the open frame generation PRs:
  • feat(dlss): NVIDIA DLSS Frame Generation through Streamline (Vulkan, manual hooking, Reflex) #1944 (Streamline): I tested it on the same machine, and its exit crash and fix are in my comment there.
  • feat(vk): DLSS frame generation (NGX), more actor motion for DLSS, FidelityFX FSR 4 fallback (builds with #1833, #1834) #1831 (NGX): it was the starting point for this path; its MvecScale 1 was right.
  • Overlap: happy to fold this into either if the maintainers prefer.

🤖 Generated with Claude Code

[Arkex-ai]

Tested exact head ec27f1f on an RTX 5070 Ti / Windows 11, 3440x1440 output, DLSS Quality 2294x960, game cap 60, FG 2x, pacing on. Fresh guest generation and matching API 14 host/backend build. NGX loaded the pinned official SR runtime and the DLSS-G runtime supplied with Streamline 2.14.16 from an isolated ngx directory; no Streamline interposer was loaded for this path.

NGX created its feature and logged repeated 600/600 sets made by DLSS-G, with zero refused and no fallback in those windows. Three controls used the same host/backend, copied checkpoint and active window. The controller reported 3440x1440 at 159 Hz; all three swapchains logged FIFO (V-Sync Auto). PresentMon 2.6 recorded actual display timestamps, separately from the native-present trace; no pixel capture during timing.

Phase	Off displayed/s	Built-in 2x	NGX 2x
Gameplay before pause	60.03	119.88	120.05
Inventory	60.03	119.88	120.05
First second after return	59.47	119.46	118.71
Stabilized	59.98	120.23	120.14

Native rates stayed around 60 in all modes. Displayed P95 in the first return second: 18.78 ms off, 12.51 ms built-in, 12.52 ms NGX. There was no missing display feedback in those measurement windows. Normal exit from inventory returned 0 with NGX active, and both controls also exited normally. Presented hearts/instructions and inventory text were legible in the frames inspected after timing.

This confirms the NGX path runs on this RTX 50 setup. It is one run per mode in the initial interior scene, not a latency, motion-quality, 3x/4x, fixed-refresh, or campaign test. With the game capped at 60, both FG methods reach about 120 displayed/s here; these measurements do not establish an overall winner. PresentMon marked frames Application, so individual generated-frame identity comes from neither that label nor the UI screenshots; the generator attribution above comes from the NGX set log.

[nullifyshot]

I tested this on an RTX 5080 (1920x1080 at 360 Hz, G-SYNC, driver V-Sync on, in-game V-Sync Off) at 4x, measuring input latency with DLSS-G against frame generation off. DLSS-G worked well: it made every set in gameplay ("600 made by DLSS-G" in each window). It adds a fair amount of latency, though, and part of that is because NVIDIA Reflex is off while it runs.

How I measured. The game pressed its own buttons through HOS_INPUT_LIVE. A local log line (not part of this PR) recorded when each press was due, on the QPC clock. Desktop Duplication timed the first composed frame that showed the reaction, using LastPresentTime on the same clock. That covers the game's input read through to the frame on the desktop. It leaves out the controller and the monitor. I used 20 presses per action, with Link idle in the same spot each time.

Action	DLSS-G 4x	Frame generation off	Difference
Camera flick (right stick)	37.8 ms	25.7 ms	+12.1 ms
Sword (Y)	62.5 ms	45.1 ms	+17.4 ms
Walk (left stick)	64.3 ms	46.6 ms	+17.7 ms

These are medians. The 10–90% range was about ±5 ms around each, and the two modes don't overlap. The game's own frame rate was about 77 fps with DLSS-G and about 99 fps with frame generation off.

Reflex is off whenever frame generation is on, DLSS-G included.

• The code: on() in gpu/vk/vk_reflex.cpp requires !framegen_on(). That check gates the sleep, every marker and the timing log. Anti-Lag 2 has the same check. This PR doesn't touch either file, and vk_dlss.cpp never calls into Reflex.
• In game: with Reflex set to On + Boost and RX_VK_REFLEX_LOG=1, a DLSS-G session wrote no Reflex timing report in over 10,000 frames. The log writes one every 300 frames while Reflex runs.
• One quirk: NVIDIA Reflex: on + boost is still logged once after each swapchain rebuild. It looks like the sleep mode is re-applied when the latency state is reset. So the driver may keep Boost even though nothing is paced.

The frame-generation-off run had Reflex On + Boost and the DLSS-G run had none, so the gap above includes both frame generation's held-back frame and Reflex's pacing. NVIDIA's own integrations (Streamline) require Reflex while DLSS-G is on, to win back exactly this latency, so it seems worth having here too.

A possible fix. As far as I can tell, Reflex is off under frame generation because its per-frame calls assume one present per game frame. Its calls fall into two groups, and only the second actually conflicts:

• Game-frame calls, all on the presentation thread in do_present:

  • SIMULATION_END and RENDERSUBMIT_START (reflex_present_begins, vk_replay.cpp:2940)
  • the latency sleep after it, followed by SIMULATION_START and INPUT_SAMPLE (ReflexSleep, vk_replay.cpp:2941)
  • RENDERSUBMIT_END (reflex_submit_ends, vk_replay.cpp:3678)

  These still describe the game's real frames with frame generation on, and the sleep that paces them is where the latency gets won back.

• Present calls: the present id and PRESENT_START/PRESENT_END (reflex_present_id, vk_replay.cpp:3704, and reflex_presented, :3724). These run in the present path the display thread also uses for made frames, so they would mark made frames as if they were game frames. This is the part that clashes with frame generation.

So on() could be split into two checks:

• A game-frame check: the row is on, the device is ready and the swapchain has latency mode. It no longer depends on framegen_on(), and it gates the sleep and the simulation and render-submit markers.
• A present check: the same, plus "this present carries the game's real frame". It's always true without frame generation. With frame generation it holds only for the present of the set's real frame, and made frames get no present id or present markers. It gates reflex_present_id and reflex_presented.

RX_VK_REFLEX_LOG=1 would show it working: timing reports with frame generation on. Rerunning the measurement above would show what it wins back. Anti-Lag 2 could probably get the same split. I haven't tried any of this, so take it as a direction, not a tested patch.

[pmwork-personal]

Thanks @Arkex-ai for the 5070 Ti run, and @breakthetargets for the latency numbers and the Reflex write-up. I pushed your split as a new commit here (feat(vk): NVIDIA Reflex with frame generation):

• Kept with frame generation: the calls that describe the game's frame. That's the latency sleep, the simulation/input markers after it, simulation end + render-submit start at do_present, and render-submit end once the set's recording is submitted (reflex_game_submitted).
• Present calls: each set keeps the game frame it was made at (reflex_frame()). On the display thread only the set's real frame is presented with that present id and PRESENT_START/END. Made frames get neither. A deferred (present-ahead) present carries it in its PendingPresent.
• Present ids only go up. One that wouldn't (frame generation toggled with sets in flight) is left off, and a new swapchain starts again.
• Without frame generation nothing changes. test_reflex_swapchain_lifetime.py covers the new cases.

On the 5090 (5120x2160, DLAA, Reflex On + Boost, same spot), Reflex's own timings (RX_VK_REFLEX_LOG=1) now show up under DLSS-G. Before, it wrote none:

	game fps	sim start → present end
frame generation off	~61	15–16.5 ms
DLSS-G 3x	~54	41–42 ms

That's Reflex's view, so it can't show what turning Reflex on under frame generation wins back: with Reflex off there's no timing to compare against. @breakthetargets, could you rerun your input-to-screen measurement on the new head? That's the comparison that counts.

Most of the remaining gap is the interpolation itself: the real frame is shown after its set's made frames, about ⅔ of a game frame later at 3x.

[nullifyshot]

Thanks for the quick follow-up. I reran the same test on 3a39e3f, with the same PC, settings, spot and method as my comment above. This time RX_VK_REFLEX_LOG=1 was set in both modes.

Reflex now runs with DLSS-G. The DLSS-G run wrote 59 Reflex timing reports while DLSS-G made every set. Before this commit it wrote none.

Action	DLSS-G 4x + Reflex (3a39e3f)	Frame generation off, Reflex on	Gap	Gap before 3a39e3f
Camera flick	38.3 ms	25.3 ms	+13.0 ms	+12.1 ms
Sword (Y)	62.9 ms	47.6 ms	+15.3 ms	+17.4 ms
Walk	61.6 ms	48.9 ms	+12.7 ms	+17.7 ms

These are medians of 20 presses each. The walk gap shrank by about 5 ms and the sword gap by about 2 ms, but part of that may be run-to-run noise. Overall, the latency barely changed. Reflex's own timings show why:

	Simulation start → present end	Simulation	Game's own frames/s
Frame generation off	10.1 ms	9.5 ms	~97
DLSS-G 4x	20.9 ms	12.0 ms	~77

• Off: a frame reaches its present about 0.6 ms after its simulation ends. This scene isn't GPU-bound, so there's no queue for Reflex's sleep to drain, with or without frame generation.
• DLSS-G: the extra ~11 ms is the game frame held back while the set's made frames are shown first. That's built into interpolation, and Reflex can't remove it. Each game frame also takes longer (12.0 vs 9.5 ms of simulation, ~77 vs ~97 fps). If the presentation thread is waiting on frame generation's work, that may be worth a look too.

So the change looks right. It should pay off in GPU-bound scenes, where frames do queue up: higher resolution, heavier settings or a slower card.

One thing looks off: the GPU-end timing with frame generation. With frame generation on, Reflex's "to the GPU's end" reads 243–442 ms, next to about 21 ms from simulation start to present end. With frame generation off it reads a sensible 12.1 ms. It looks like the driver is pinning the GPU's end of a frame on later work.

A possible fix (untested, just a direction). Hookshot never chains VkLatencySubmissionPresentIdNV to its queue submits. That's VK_NV_low_latency2's way of telling the driver which frame a submission's GPU work belongs to. Without frame generation the driver seems to infer it correctly. With frame generation, the display thread's copy and DLSS-G submits sit between the game's frames, and it probably gets them wrong. What I'd try is tagging every submit through one helper, much like reflex_present_id, for example reflex_submit_id(const void* next):

• The game's rendering: submit_recording, including the batched path through queue_flush_locked, and the parallel recording jobs' submit (vk_replay.cpp around line 1555). Chain VkLatencySubmissionPresentIdNV with the frame being made (r.id while frame_marked, between its simulation start and its render-submit end).
• present_image's submit (around line 3682): use the same rule as the present id. That's r.id without frame generation, the set's game frame (reflex_present_frame) for the present that carries it, and no tag for made frames. That way the made frames' copy and DLSS-G work isn't counted as the next game frame's rendering.

If this is the cause, RX_VK_REFLEX_LOG=1 should show "to the GPU's end" back below "simulation start to present end" with frame generation on, as it is with frame generation off. The driver would then also be pacing on correct GPU timings. I haven't tried this, so it's a lead to check, not a confirmed diagnosis.

[pmwork-personal]

Thanks for the review. The four inline points are fixed in a new commit, 90c4683 fix(dlss): DLSS-G only where it runs (replies in each thread). The Reflex submit tagging (VkLatencySubmissionPresentIdNV) is now in the description as a follow-up.

From #1831's side:

• Method choice as a pure header with a unit test: I can move the Frame generation by choice into a small header with a test here, if that helps the review.
• DLSS-G without a temporal upscaler: here its inputs come from the temporal chain, because that's where the actor motion is. DLAA (the Upscaler's Native) covers the no-upscaling case. Decoupling it could be a follow-up.
• Single/pair/no-weight actor-motion layouts: I'll open them as their own PR next, with credit.

Agreed that the choice between this and #1831 is @NotRexed's.

[pmwork-personal]

Thanks for the approval. Main is merged in again (#2042 touched the Reflex row), and the nit is fixed in 7c13821. I'll take the method choice as a small header with a unit test in the follow-up, together with DLSS-G without a temporal upscaler, and the single/pair/no-weight actor-motion layouts as their own PR, with credit to FIocker.