Fixes from the issues (#11, #12, #13), a card that says when the recorder is the problem, and a test option for a full card that is safe to try. Nothing here changes a picture unless an option is turned on, except the ultrawide fix (issue #13) and the Auto quality hold, which only act in the cases they were made for.
- A fault in the upscaler's pass says where it was. The log line for an exception in the DLSS scaler ("DISABLED: exception 0x...") now also gives the module and offset (and what an access violation touched) and the step the
pass was at, so a report of one can be found in the code; the offline test host prints the same for a crash on any thread. - "Record what is shown" keeps the middle 1920x1080 of each presented frame, and the card says when the recorder is the problem. The owner's first recordings of what is shown (4K, HDR, frame generation x2) kept 84 of 247 frames
and compressed to more than their raw size: a 4K HDR frame is 66 MB and every presented frame is copied. The middle of the frame at full size (an even offset) is kept instead, a quarter of the data, which a card in use can
copy; a flicker shows in the middle as well as anywhere. And "What stands out" now says "Recording is on ... it is the first thing to rule out when frames are uneven" (a problem when they are, a note when they are not): the same
session's log showed a full card (the model waiting 19.7 ms, a picture 1,016 ms late) exactly while the recorder was saving. nr_lsrec flicker <recording>: for a recording (of what is shown, with "Record what is shown", or of anything) how much the picture changes from one frame to the next, by kind of pair, the biggest steps with the time between
frames, and whether the change pulses at a period: the objective side of "it flickers".- The panel says whether your model file is a build seen working. People have different
nvngx_dlssnr.dllfiles, and a name, a version and a size do not tell two builds apart (issue #12: an RTX 4080 refused a file that looked like the tested
one). The Requirements check now makes the file's SHA-256 (the first 16 hex digits) and says "a build seen working (file 4b8d...)" when it is on the list, and, for a file with the tested version and size that is not, "not the same file":
the first thing to check if the compatibility test fails. The list (kKnownModels, and docs/model-compatibility.md) grows with the reports people send; a build seen failing is not on it. - The compatibility report says more when the model refuses (issue #12: an RTX 4080 got "NOT_SUPPORTED", which no Ada card should). The report a person pastes into an issue now also carries: every graphics adapter the system has and
which one was tested; the first 16 hex digits of the model file's SHA-256 (a name and a size do not say whether two people have the same build); what NVIDIA's NGX said while the test ran (the last 40 lines, folders left out); and, when
the model refuses, what it does for the same feature at other sizes (1920x1080, 960x540, 640x360, 2560x1440 and 1280x720 again), which shows whether the refusal depends on the size. - Neural Rendering on an ultrawide screen with a game that is not (issue #13). A 2560x1440 game on a 5120x1440 screen is drawn by Lossless Scaling with black bars each side; the model's change belongs to the picture, but the compose
stretched it over the whole screen, which put the picture's change on the bars and misplaced it on the picture ("extreme artifacting"). The compose now works out where the frame is drawn (its shape fitted into the screen, centred) and
leaves the bars as they are, after checking that they are there (a one-pixel strip through the middle of where each bar would be, copied now and then, must be dark: in Lossless Scaling's stretch mode there are none and nothing changes); the log says so ("the 2560x1440 frame is drawn into 5120x1440 with bars", "the bars are there"). "The picture fills the whole screen" (Neural Rendering, Advanced) is for Lossless Scaling's stretch mode, where there are no bars.
New checks in the suite (nr_composebench viewport= barcheck=1, and the host scenarioultrawide_bars). - A runtime that crashed Lossless Scaling is not tried again (issue #11). The FSR Upscaler's FSR 4.1.1b INT8 runtime (chosen in the Runtimes list) closed Lossless Scaling on a Radeon RX 6600 XT as soon as it scaled a window. A runtime that is not
the shipped one is now marked "on trial" in a file (runtime-trial.txtin the addon's folder) from its start until it has upscaled ten seconds of frames or Lossless Scaling closes normally; found at the next start, the shipped runtime runs
instead and the log says why. To try it again, choose the shipped one in the Runtimes list and then the other again. - Auto quality no longer cycles between every frame and every 2nd or 3rd. The owner's trace showed it: the model skips frames, the game recovers, the governor calls that calm and goes back to every frame, the game slows again, and
so on every 40 to 60 s, each change a visible change in how the picture is made. When going back did not hold (the game was slow again within 90 s) the hold at every 2nd or 3rd now doubles each time (30 s, 1 min, 2 min, up to 10
min), and starts afresh after five calm minutes at every frame.
Measured live on the login screen (1440p to 4K HDR, frame generation x3): the test option Lighter upscaling of generated frames cut the DLSS cost from about 3.7 to 2.2 ms a presented frame, a frame-rate gain of about 20 % for the owner. It is off by default.