Notice. Not affiliated with NVIDIA; NVIDIA, DLSS and the NVIDIA logo are NVIDIA Corporation's trademarks. The bundled NVIDIA runtimes are NVIDIA's property, included unmodified as received, research/educational use only, no warranty, use at your own risk.
Warning
NeuralScreen requires the latest NVIDIA driver. Operation with older drivers or unsupported/non-standard configurations is not guaranteed.
Important
Radeon testers wanted. The AMD build lives in a separate repository, NeuralScreen-AMD, and it has not run on a real Radeon yet. Start from native/AMD.md there, and if it does not come up, attach the diagnostic package (Settings -> Program -> Create diagnostic package).
A patch on the v2.1 line, mostly Frame Generation: what it generates from, and what paces it. Plus two regressions from v2.1.5 and the NR-pass hotkeys.
Frame Generation takes only new pictures (#132)
Every frame the loop produced went into FG as a new real frame - including a pointer-only Desktop Duplication update, which carries the same pixels, and a captured window that had not redrawn. Each cost a full set of DLSS-G evaluates, and its slot, a few ms after the real one, pushed out the generated frames of the real step. That is the report: the video stuttered while the mouse moved, the counter went up, and so did the GPU load. Such a frame is now held, and FG spaces its frames by the source's own timestamps, not by when the loop got to them. Measured: moving the pointer over a still picture used to raise FG from 144 to 226 slots a second; now it stays at 144.
In window mode the capture returned at once when the window had nothing new, so a still window spun the whole loop at hundreds of frames a second on one picture - FG "did nothing" there. It now waits for the window's next frame, like the desktop capture does: 10 frames a second on a still window instead of 232.
FG is really paced by the display (#123)
The swap chain's latency waitable collects a count for every present, and ordinary presenting never waits on it. By the time FG started it held about 40, so none of the presenter's waits ever blocked - while the log said paced by the compositor (latency 1). The presenter now starts from a clean count. Measured at 4x on a 144 Hz display: the wait before each present went from 0.00 ms to one vblank, and frames dropped as late from ~95 to ~5 every two seconds.
Two v2.1.5 regressions
- A still screen no longer resets NR and FG when it moves again. Any second without a new frame counted as a capture pause, so the first scroll or video frame after a pause reset the history - a hitch exactly where motion starts. The reset now needs a capture that really missed something: closed, reopened, or a window minimised or hidden (#130 stays fixed).
- A reopened capture keeps the frame it was opened for. The #128 fix threw away the first frame of every capture session, and on a still screen that was the only frame the reopen would get. Only a genuinely empty first frame is dropped now.
Also: moving off an unplugged monitor now works when it was output 0 (#128).
Hotkeys for the NR passes (#126)
Num+ and Num- step the cascade one pass up or down (1 to 4), rebindable in Settings -> Keys. The alert shows what really runs: the cascade needs Boost, and a frame too small to step its work size aside runs one pass. They are on the numpad on purpose - a global hotkey takes its key from every program, and the main row's minus is typed far too often.
Thanks to manik1627, Uporabnik332 and x-nihil0, whose packages and measurements pinned these down.
Tests
New, each failing on the code before its fix: test_fg_fresh_frames (still window, a 30 fps window, the pointer over a still picture), test_fg_waitable_drain, test_capture_pause_reset, test_dda_reopen_pixels, test_nr_passes_hotkey, and a vanished-output-0 case in test_monitor_resize.