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, built from a contribution: file conversion gets faster, and the panel gets a theme and a shorter mode.
Conversion: a frame stops travelling through the pipe
Converting a video used to hand every frame to the worker and take it back through a pipe - the same 8 MB at 1080p, written and read, twice per frame. Both directions now use the shared mapping the live pipeline already uses, and the motion field travels at ~320x180 and is upscaled on the GPU instead of being built at the working size on the CPU.
The three stages - decode, the network, encode - also run on their own threads now instead of one after another. Each channel is asked for separately and each can be refused: a worker that does not take one keeps the old path for it and says so in the log. NS_CONVERT_PIPELINE=0 puts the stages back on one thread, which is how a pipeline bug is told apart from a conversion bug.
Measured here on a real recording (1478 frames of 640x360) with the product's own converter, same file, both settings: 13.2 s serial against 9.0 s overlapped at the default work scale, and 14.3 s against 10.0 s at 1:1 - 1.4x, with identical output bytes. The contributor's own numbers are per-stage CPU costs at 1080p (13.7 ms of guides to 6.0, 2.7 ms of tobytes and 6.2 ms of pipe to 0.9 ms of copy, returned pixels 0.4 ms instead of about 3), and how much of that reaches the wall clock depends on which stage is the bottleneck on your card and your source. A short clip at a small frame size does not exercise the copy the same way a 1080p or 4K one does.
A contrast theme
A third theme beside light and dark: near-black background, phosphor-green text, a single monospaced face for every role - the terminal look, and the reason the program stopped using one face for everything in 1.6.0 is an objection to the look, which is what this theme is for. It sits on the same settings page as the other two.
One thing to know: the theme list lived in three places and only two of them were updated, so contrast was accepted, applied, and then silently reverted to light on the next restart or monitor switch. There is one list now and every offered theme survives a rebuild; test_theme_rebuild checks each of them against the real rebuild and fails if a whitelist is ever duplicated again.
Mini mode
The panel can be cut down to the rows you actually use. An icon in its header switches mini mode on, and a second icon appears while it is on to choose which rows the short panel keeps - NR, Frame Generation, Boost, the profile, whatever you want. The choice is saved; the choosing state is not, so a restart does not leave you in it. At the default scale that is 1213 px of panel becomes 372.
Also
The converter's colour tags now land on the frame as well as the stream, which is the mismatch that showed as flat contrast in some players. Two new tests cover the overlapped pipeline (same frames, same order, same timestamps as the serial loop, and a cancel stops all three stages) and the mini-mode header.
Updating
Unpacking over the previous folder is fine and keeps your settings.
Tests
The full suite before tagging: 225 checks, 5 skipped, 0 FAIL in 475 s, including the GUI cycle. The skips need an HDR display in HDR mode or are opt-in.