enricobuehler aef552f04a feat(host/windows): HDR scRGB→P010 in a shader — NVENC native P010, off the SM ...

On the Windows WGC HDR path the FP16 scRGB capture was fed to NVENC as
R10G10B10A2 (BT.2020 PQ), and NVENC did the RGB→YUV CSC internally on the
contended SM — adding to the encode_ms wall under a GPU-saturating game.
(NVIDIA's D3D11 VideoProcessor can't do RGB→P010 for HDR; that path renders
green, confirmed live — so the convert must be ours.)

New `HdrP010Converter` fuses the tone-map with the BT.2020 RGB→YUV matrix and
emits P010 (10-bit limited range) directly: a luma pass → an R16_UNORM plane
RTV (full-res) and a chroma pass → an R16G16_UNORM plane RTV (half-res, 2x2
box average) of a DXGI_FORMAT_P010 texture. NVENC then takes native P010 and
skips its SM-side convert.

Gated behind PUNKTFUNK_HDR_SHADER_P010 (default OFF → the existing
R10→NVENC path is byte-for-byte unchanged). Colour validated by a new
`hdr-p010-selftest` subcommand: a synthetic scRGB pattern → P010 → readback,
compared to a BT.2020 PQ 10-bit reference — max abs error Y=0.99 / Cb=0.82 /
Cr=0.75 codes on an RTX 4090. Live-validated HDR colours correct (no green).
Build + clippy (--features nvenc -D warnings) green on x86_64-pc-windows-msvc.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-19 09:54:00 +00:00

..

protocols

rename: lumen → punktfunk, everywhere

2026-06-10 13:11:59 +00:00

src

feat(host/windows): HDR scRGB→P010 in a shader — NVENC native P010, off the SM

2026-06-19 09:54:00 +00:00

build.rs

fix(dist): kill the version-shadow + add build provenance (P0)

2026-06-15 10:30:21 +00:00

Cargo.toml

refactor(host/windows): clean up DDA path + add a proper Windows service

2026-06-16 18:44:15 +00:00