MpcVideoRenderer-DLSS5-1.5

MPCVR-DLSS5 1.5

Since 1.45. This release fixes what 1.45 broke, corrects what it told you, and puts the fork
back on upstream's own behaviour wherever it had quietly drifted off it. It also carries
upstream's development up to 0.10.8. Everything below was measured on an RTX 3050 with the
tools in tools/dlssnr_probe, and the numbers are theirs.

RTX Video HDR and RTX Video Super Resolution work together on a 10-bit source

The stock renderer does both at once on a 10-bit film. 1.45 did not, and its colours were
flatter. Both were the same fault, and it was ours.

Upstream keeps the video processor out of PQ passthrough unless the source is 8-bit.
Passthrough tells the processor that its input and its output are PQ BT.2020, which only holds
once the driver's extension has taken the picture over; where it has not, the processor reads
an SDR picture as PQ, and that is the flat colour. Upstream's commit that fixed this says so
in its title -- "RTX Video HDR now works with 10-bit SDR video too" -- and 1.45 removed the
line it added.

Measured on the current driver, how much enabling RTX Video HDR changes the picture, in 8-bit
levels:

Input	processor in PQ passthrough	processor left in G22/P709
NV12 (4:2:0, 8-bit)	37.1	36.9
P010 (4:2:0, 10-bit)	0.000	36.7
AYUV (4:4:4, 8-bit)	37.9	37.7
Y410 (4:4:4, 10-bit)	37.7	37.5

The depth was never the reason. The line is upstream's again, word for word.

End to end on a 10-bit AV1 film, decoded in D3D11 and arriving as P010 1920x800 into a
3200x1334 window, against a build of upstream's own current master driven with the same
settings:

every option off	byte-identical to upstream (99 dB)
Super Resolution alone	byte-identical to upstream; upstream leaves it off on a 10-bit source unless RTX Video HDR is on, and so do we
RTX Video HDR	the displayed picture moves 19.91 dB, and the statistics read D3D11 SuperResolution* and RTX Video HDR* together
Super Resolution beside it	49.35 dB, and the detail 0.4095 → 0.5272

Upstream's own master does not survive that case at all: a 10-bit source on an HDR display
with RTX Video HDR on dies with 0xC00000FD, a stack overflow in an unbounded recursion
between the video processor's set-up and the swap chain's. The bound added in 1.45 is what
carries this fork through it.

What 1.45 told you, and what is true

1.45's statistics, tooltips and manual said the driver leaves a 10-bit 4:2:0 picture untouched,
and that ticking Replace VP chroma upsampling was what gave RTX Video HDR something to work
on. Both were wrong, and so were the figures that went with them.

The measurement behind them had put the processor into PQ passthrough before asking -- the one
arrangement in which the extension does nothing. And the end-to-end figures came from a bench
whose --file named a film but never built its graph: every "film" run played the bench's own
800x450 RGB32 pattern, which the renderer converts with shaders and which never brings the
hardware processor into the chain at all. Neither extension could have shown.

So:

• the statistic RTX Video HDR (no tone mapping on 10-bit 4:2:0) is gone; the star is
  unconditional, because the driver really does tone map every picture the renderer gives it;
• the figures 52.25 → 30.19 and 49.60 → 51.61 are void. Measured again on a real
  10-bit film, the same configuration moves 51.61 → 30.38 -- the 8-bit signature;
• every tooltip on the Settings page was rewritten: what the box does, what it needs, when it
  greys, and the one measured number that decides the choice. They run 2 to 9 lines against 2
  to 18, and the three that described the behaviour of two versions ago are correct now;
• the manual carries a Corrections section listing all of this rather than quietly dropping
  it.

A silent incompatibility with any host built against upstream's header

This fork had put a method of its own in the middle of IVideoRenderer, and a field of its own
in the middle of Settings_t, while keeping upstream's interface identifier. Everything after
them moves: a player or a tool built against upstream's header reached SetSettings when it
asked for GetSettings, and SaveSettings when it set them -- so driving this filter did
nothing at all, and quietly wrote its defaults to the registry.

Both now come after everything of upstream's. Nothing you have saved moves: the settings are
stored by name.

Super Resolution and the 4:4:4 pre-pass

The driver does nothing with a 4:4:4 picture -- 0.000, against 4.011 on NV12 and 3.903 on P010,
with or without RTX Video HDR. 1.45 answered that by not asking for the extension at all; this
release asks for it exactly as upstream asks, and answers in the interface instead:

• Request Super Resolution greys while Use for resizing and Replace VP chroma upsampling
  are both in service, because a control that cannot change the picture should say so;
• the scaling line reads D3D11 (No Super Resolution when chroma by shaders) instead of
  starring work nobody did;
• an interlaced source keeps the processor's own chroma, so there the pre-pass stands aside and
  the control stays live.

Upstream 0.10.8

The fork now carries upstream's development up to 0.10.8, merged with the procedure in
MERGING-UPSTREAM.md: the pre-flight check tools/upstream_check.py, reserved resource-id
ranges so a merge can never give two resources the same number, the one-command battery
tools/dlssnr_probe/run_all.cmd, and a set of reference numbers to compare against.

Measuring

playback_test --file now decodes the real film instead of the bench's pattern, takes its
picture on a frame it seeks back to so two builds can be compared frame for frame, reads any
build's own statistics off the window, and prints back the settings the filter kept -- which is
what caught the interface fault. vp444_probe can ask for an HDR output without the
passthrough, which is the measurement this whole release turned on.

The full battery: 17 steps, 0 failures, 2443 rows compared against the reference, 4 moved.

---

Built with Visual Studio 2022, x64 and x86, without a warning.