Skip to content

v0.3.23 - the arm the three probe runs could not isolate gets a launcher

Choose a tag to compare

View all tags
@perseval-BLR perseval-BLR released this 25 Sep 15:37
v0.3.23
a68a298

v0.3.23

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

What the runs showed

#3 (RX 7900 XTX). The third run was clean: no flicker, and not one frame above 1024 in the upscale's output - 0 of 68 samples, against 34 of 69 on the baseline and 59 of 68 on the private copy alone. The reporter checked that the run was real (upscale on in 68 of 68 samples, 67 frames processed, 14 network jobs), so those numbers come from a run that worked, not from one that did nothing.

Two things in it are still open, and he said so himself:

  • the presented surface sits at 0.916 x the native anchor, where the clean frames of the other runs sat at 1.016 and 1.306 - so the result may be arriving attenuated, and that is not yet confirmed either way;
  • the run changed two things at once, and "motion vectors without the private copy" has never been run in a build where it could answer anything.

#6 (RX 9070 XT). A second reporter on a different card generation, and his log shows the same defect from a different angle: with the upscale in the path, 4 of 12 sampled frames present a black surface (mean 0.0000 against a live native anchor of 0.3434); with it out of the path, none do. In the 1:1 segment, where the upscale does not exist, it is clean. Same class as #3, on another GPU.

What is new

A launcher for the arm the three runs could not isolate: NeuralScreen-probe-mv-shared.vbs.

It is the per-frame probe with motion vectors bound on the shared upscaler module - the same file the runtime's hooks are in. The other two launchers cover the private copy without vectors and the private copy with them; this one is the fourth corner of that 2x2, and it is the one #3 asked for. The private copy is deliberately not set, so the runtime can see this dispatch.

Worth saying plainly: this is the combination that in v0.3.21 drove the runtime into a staging re-create loop (80 re-creations for 4 network jobs). v0.3.22 did not fix that loop - it moved the upscale onto a private copy so the runtime never saw it. So this run may hit the loop again. If it does, the picture still answers the question it was built for (does the flicker stop), and the worker's log says which happened.

Nothing changes for the default path: the launcher is a test, the arms are off unless a launcher turns them on, and the defaults are v0.3.22's.

If you can help

Same window, work scale below 1.00, and the same order as before, so the runs stay comparable:

  1. NeuralScreen-probe.vbs
  2. NeuralScreen-probe-private.vbs
  3. NeuralScreen-probe-mv.vbs
  4. NeuralScreen-probe-mv-shared.vbs (new)

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

What did not change

Defaults, the neural pass, the capture path and the menu are v0.3.22's. The flicker is still open. The vectors now have a clean run behind them and a way to isolate them; the attenuation question in #3 is unanswered, and that is the next thing to look at.

Assets 8
Loading