A major bug fix for HDR, and a steadier Neural Rendering. With HDR on, sharpening could turn a highlight into a white speck up to 10,000 nits bright; that is fixed in all three upscalers. The same
release lowers the flicker of Neural Rendering (auto quality no longer ramps, the smoothing trusts its history where the picture is unchanged), sharpens less where the picture moves fast, and the
FSR Upscaler now sharpens the way the DLSS and XeSS Upscalers do. The HDR fix comes first; the rest is below it.
- HDR: sharpening could turn a highlight into a 10,000-nit speck. The HDR view's roll-off is steep at its top (a view of exactly 1.0 is 125 times the SDR white), and the
sharpening passes and the picture controls (brightness, contrast, gamma, shadows, highlights, saturation) work in that view and put only their change back into the light: a bright pixel
that a change nudged to 1.0 came back as a white speck. Found by running the upscaler on an HDR recording in fp16 (newnr_sreval hdr=1): the peak light of the output was 125.75 against
1.20 in the input. Now a change made in the view goes back onto the light within 1.5x of it (plus 0.5 of the SDR white; dark and mid tones are untouched), and the sharpening's result stays
within 15 % of the range of its neighbours' light (no ringing; not applied to SDR). On the same footage the peak is 1.44; the mean light is kept (out / in 1.003) and the scores are the
same. Covers the plain and the steady sharpening passes (DLSS, FSR, XeSS) and the picture controls of the upscalers. A test for it (a made-up HDR clip with bright glints) is in the
Neural Rendering suite oftools/run_addon_tests.ps1. - "Sharpen less in fast motion" (0.5 by default) in the upscalers' panel. The eye cannot resolve the extra detail sharpening adds where the picture moves fast, but it does see
the shimmer sharpening amplifies. The sharpening is lowered smoothly from 1 to 8 pixels of motion a frame, by this much at the fastest; at rest and in slow motion it is untouched.
On a recording walking over cracked ground at 1:1 (DLSS model E, sharpening 0.45): flicker added over the game's own 113 % -> 107 % at 0.5 (102 % at 1.0), detail kept 137 % -> 127 % (117 %):
more detail for the same flicker than simply sharpening less (which would keep about 121 % of it for 107 %). Upscaling 1.5x, scored against the true picture, 0.5 is better than off
(Silent Hill f 43.82 dB against 43.01, steadier 41.21 against 40.43), at the same pass cost. Works for DLSS, FSR and XeSS. - Neural Rendering's temporal smoothing trusts its history more where the game's picture is unchanged, and starts at 0.7 (was 0.4). Where a pixel's brightness matches what was kept
with its history (the same surface), any change in the model's output is the model's own noise, not new content, so the history weight there goes up to 1 - (1 - setting) / 4 (0.95 at 0.8,
at most 0.97) while the setting still rules where the frame changed. From the design notes of the Magpie fork (docs/magpie-fork-study.md), measured withnr_nrevalon your own clips,
the model's change where the game's frame is still, in levels of 255 (Durotar, working scale 0.3: setting 0.4 -> 0.72 before, 0.43 now; 0.8 -> 0.40 before, 0.29 now; character screen: 0.4 ->
0.42 before, 0.20 now; 0.8 -> 0.21 before, 0.11 now). Existing settings keep their value (the slider is on the panel's Neural Rendering page). - Neural Rendering's auto quality no longer ramps. In a live log it started at 1.00 and stepped down nine times in 100 s (1.00, 0.90, 0.80 ... 0.25), and each step rebuilds the model with no
history: the picture changed look every few seconds, and 2 to 6 % of presented frames had no change applied while it rebuilt (up to 82 % while a 6 GB recording was being saved). Now it
(1) goes straight to the resolution where the model's time is expected to fit, from its measured time and area (fixed cost and per-area cost from two measurements), in two changes
from 1.0 instead of nine; (2) starts from the resolution it last held for 30 s within budget (autoScaleLast, kept once a minute at most); (3) tightens the budget in proportion when
the game's own frame time is well over the best it has lately managed (the card is out of room), and does not go back up for a minute; the log says when it did. - With frame generation, every other presented frame keeps the motion estimate of the one before ("Share motion between generated frames", on by default; it does nothing
without frame generation). Two frames are shown for each one the game draws and the motion from one to the next is about the same for both steps. The estimate's time
fell from 0.39 to 0.23 ms a frame on average at 4K with the same scores on the recordings (used here as a harsher test: their steps are whole game frames, not halves). - The passes after the upscaler move fewer bytes. In HDR they are limited by memory traffic (about 0.97 ms at 4K in one log, six 66 MB pictures read or written): Steady
sharpening's running average is now kept in 10 bits a channel (4 bytes instead of 8; it holds the SDR view, 0 to 1) and is not read at all where the pixel moves too fast to
trust it. The same quality on the recordings; the gain shows in HDR (nr_sreval bench=Ntimes the passes back to back). - Steady sharpening is on by default (0.6) and no longer says "test". The FSR Upscaler now sharpens with the same pass as DLSS and XeSS instead of AMD's RCAS, so it gets
Steady sharpening too and the Sharpening slider means the same on all three: at 0.5, RCAS left 73 to 83 % of the game's detail while the pass leaves 101 to 112 % (as it does for
DLSS and XeSS), and FSR scored about 0.5 dB closer to the true picture upscaling 1.5x. Saved settings keep their value. - Steady sharpening trusts its running average less where the picture moves fast and is now a single pass (cheaper than the two passes and a copy it was in
0.9.21). Upscaling 1.5x it now scores within 0.1 dB of no steady sharpening (0.9.21 lost up to 0.96 dB on a moving clip); at 1:1 it keeps its gain on a nearly still scene
(docs/frame-generation-research.md).