v0.3.20 - the per-frame probe is a one-click launcher
v0.3.20
Sensitive to flashing images? See the note in v0.3.13 - it still applies.
The per-frame probe is now a double-click
The probe that answers "which surface is at fault" was already in v0.3.19, and it was already out of reach of the people it was built for.
It reads the surfaces every 300th frame. A readback is a full GPU-to-CPU sync, so that cadence is deliberate - but a diagnostic run is short: one reporter's three launches ran 51, 73 and 216 frames, so the modulo never fired once and the numbers that would say which surface alternates are absent from his log. The instrument existed; its cadence put it out of reach of the reports it was made for.
Turning it to every frame takes an environment variable, and that is where it stopped. Asked to set it, a reporter answered:
Sorry that I have no experience with coding, and I don't know how to set the NS_AMD_PROBE_EACH=1 environment variable. PLS tell me how I can do that in detail.
He is not short of willingness - he had already attached three diagnostic packages. The instruction was wrong for the audience. This project already had the answer for exactly this situation: NeuralScreen-diag.vbs exists so that nobody ever touches NS_PHASE by hand. There is now NeuralScreen-probe.vbs beside it, and that is the whole instruction: double-click it instead of the usual launcher.
Same pre-flight checks as the other two launchers (the interpreter, the runtime, the worker), the same tray behaviour, the same log. The picture runs slowly while it is up, because that is what a per-frame readback costs. It is a diagnosis for one run, not a way to play - the README says so in both languages.
tests/test_probe_launcher.py keeps it honest: it starts each of the three launchers for real, reads what the child process inherited, and fails if the variable is set in the wrong scope - the one mistake that reads perfectly in the source and does nothing at runtime.
Frame Generation is refused on a Radeon instead of crashing the worker
Carried from v0.3.19, unchanged - repeating it here because these comments are where people arrive.
A reporter on a 9070 XT turned the FG switch on and the worker died 21 ms later:
[fg] UI: on, 2x
[crash] ACCESS_VIOLATION (0xC0000005) at nvngx.dll + 0xCA05,
tried to read address 0x0, amd active=1 frames=1293
nvngx.dll is our own worker, so that fault was our null dereference, not the runtime declining politely. Frame Generation is an NGX feature end to end; a Radeon has no NGX, and the path was entered anyway.
The refusal is decided in one place, FgRequested - the single gate both FG paths ask - and it returns false on a Radeon before it consults NS_FRAMEGEN or the menu switch. The guard reads the adapter actually chosen, not "is the AMD pass live": a pass that failed is exactly when someone starts trying the other switches. The menu now draws the row as unavailable with the reason under it, and the hotkey refuses with the same text.
What did not change
The neural pass itself, the FSR chain, the capture path and the menu are v0.3.19's. This release is the launcher and the two READMEs.
The flicker is still open. It is localised, not fixed: the FSR upscale's output surface is the single remaining candidate, from three independent measurements, and NeuralScreen-probe.vbs is how the fifth measurement gets taken. If your picture flickers, run it once and send the package.