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.
Neural Rendering for the whole Windows desktop, with Frame Generation, Boost, recording and twelve languages. This release is about what a report could not tell us: Frame Generation ran only while Neural Rendering was on, the self-test never passed, and half of every log arrived without a time.
Fixes
Frame Generation now runs while Neural Rendering is off (#104). A user turned NR off and left FG on: the switch reached the worker, the frame counter kept climbing, and the presenter never started. His log held three [fg] lines - all three the switch state, none the feature - and no failure line either, so it had not tried and failed; it had never started. A second user's package showed both sides in one session: with NR on, FG reported 81.9 FPS real + generated; with NR off, not one presenter line. The bypass path stopped the presenter on every frame, and the reset flag kept it non-interpolating even when left running. FG now presents the raw capture when NR is off, and its history resets once on the switch between the neural result and the capture, not on every frame of the mode. Measured with NR off from the first frame: [fg] Init_Ext, 2x enabled at, 118.7 FPS (real + generated). Not verified: HDR + bypass + FG - that needs an HDR display this bench does not have.
The self-test reported 0/300 and now reports 300/300. --test created the feature through the DLSSNR runtime and evaluated it through the NGX core - a different implementation that knows nothing about that handle - so every evaluate answered 0xBAD00004 (FeatureNotFound) while the live pipeline was healthy. Both halves now use the same runtime and the same shared parameter block.
Half of every log had no timestamp - 499 of 916 lines in one package, 76 of 153 in another. The worker stamps its own lines; the Python side did not, and the untimed half is exactly the half a report needs: "the menu opened 21 times" could not be placed against "the user minimised a window" when neither line carried a time. Every line now carries HH:MM:SS.mmm, a worker line is not stamped twice, and the header carries the date. The menu close is logged too, with how long the menu had been open: the close button and Esc set the flag silently, so a package read "21 opened against 0 closed", which cannot be interpreted.
The diagnostic package says how the program was configured. It carried no configuration at all, so no report could answer whether Frame Generation was on, at which multiplier, or which motion backend was running. The bundle now carries a settings section: an allow-list of product keys, built from the live config, with hotkeys, directories and presets dropped and values bounded. The header gained a switches line as well.
The first hotkey press in a game did nothing. The polling fallback took the key's state as its baseline on the first sample, so a press that arrived before it was recorded as "already down" and dropped. The baseline is taken when the hotkey is registered.
The status line stays one row: state and card on the left, the rates anchored to the right edge, FG at the edge.
Tests
176 checks: 174 pass, 2 skipped (opt-in GPU tests), 0 fail; tests/autocheck.py reports all checks pass.
Every fix is guarded and each guard was proved by mutation. FG path: six mutations each turn it red. Self-test: five. Log: eight, including a missing field on the pipeline state - a real crash this release nearly shipped, caught by the window-mode test and bisected to the file. Diagnostic settings: seven, two of them on what must NOT travel.
What is still open
HDR + NR off + Frame Generation is untested (no HDR display on the bench). Frame Generation artefacts on UI and text are unchanged: the guides are flat depth and estimated motion, and HUD protection remains a proposal, not a feature.
The release procedure is written down now (RELEASING.md), and the release history is in CHANGELOG.md - both reconstructed from the code and the published releases rather than from memory, because a release cut from memory got three things wrong in one day.
Important
Radeon testers wanted. The AMD build lives in a separate repository, perseval-BLR/NeuralScreen-AMD, and it has not been run on a real Radeon yet. If you have one, start from native/AMD.md there, and attach the diagnostic package (Settings -> Program -> Create diagnostic package) if it does not come up.