v0.3.22 - the upscale can run where the runtime cannot see it

v0.3.22

Sensitive to flashing images? See the note in v0.3.13 - it still applies.

What the v0.3.21 runs showed

#3 (RX 7900 XTX). The composition line answered its question: the white frames are ordinary finite numbers (84-100% of the picture above 1024), not NaN or infinity, and the network's own surface never carries any. So they are made inside the FSR upscale step.

Two more things came out of that log:

• The frame after a history reset is always the first bad one. The reset frame itself is clean, every time. The fault lives in the upscaler's frame-to-frame history.
• With motion vectors bound, even the warm-up frames were clean - frames where the neural pass had not run yet, and which on the default path alternate clean / 83.8% wrong. That points at the missing vectors.

But that second run was not clean evidence, and the reporter said so first: with vectors, the neural runtime - which follows the dispatch that has motion vectors - stopped ignoring the upscale and re-created its staging 80 times for 4 network jobs. The run measured that loop as well as the vectors.

#1 (RX 9070 XT). Both runs stopped before the first frame, at the FSR setup, six launches in a row. The upscaler DLL, the driver and the code at that point are the same as in v0.3.20, so this looks like the state of the machine rather than the release - a restart A/B is asked for in the thread. It cannot be ruled out from the logs, which is why this build logs that step.

What is new

The upscale can run where the runtime cannot see it. NS_AMD_UPSCALE_PRIVATE=1 runs the upscale step on a second copy of the same FidelityFX DLL, loaded from a private folder, that the runtime never hooked. Same file, same name, only the folder differs. The log says whether the copy loaded; if it did, the runtime's own log stops saying it is ignoring a dispatch without motion vectors.

Two launchers use it, and they differ in exactly one thing:

• NeuralScreen-probe-private.vbs - the probe, with the upscale on the private copy. The control.
• NeuralScreen-probe-mv.vbs - the same, plus motion vectors for the upscale. This launcher changed: in v0.3.21 it bound the vectors on the shared DLL; now it uses the private copy, so the runtime stays out of the test.

A stop before the first frame now names its place. Each FSR setup call is logged before and after (FSR setup: ... calling / returned), and if one has not returned after 4 seconds, a second line says which one is still open. It only reads and logs.

Both arms are tests, not fixes, and are off unless a launcher turns them on. Defaults are unchanged.

If you can help

Same window, work scale below 1.00 (0.65 on a maximised window), one run each, in this order:

1. NeuralScreen-probe.vbs
2. NeuralScreen-probe-private.vbs
3. NeuralScreen-probe-mv.vbs

Run each until it flickers (or for 20-30 seconds if it does not), close it, then send the diagnostic package and native\dlssnr_on_amd.log after each run - the runtime's log is appended to, so it is fine to send it once at the end if you note which run was which. All three are slow on purpose.

If you are on #1 and the program stops before the first frame: restart Windows first, then run the plain NeuralScreen.vbs once. If it still stops, the log will now say where.

What did not change

Defaults, the neural pass, the capture path and the menu are v0.3.21's. The flicker is still open, narrowed to the upscaler's history and, most likely, its missing motion vectors. These three runs decide the next step.