With M_RELAXED, layer_m.comp's MLP adds every 32-channel chunk's products to
the binary16 residual stream and rounds it again: one f32 -> f16 -> f32 round
trip per chunk and element, 4 to 16 chunks a layer. M_RESIDUAL_F32 seeds an
f32 accumulator from the residual before the MLP, adds every chunk to it
with plain multiply-adds and rounds to binary16 once after the last chunk.
It needs M_RELAXED (#error otherwise); compile_m.py builds it into every
layer_m.comp stage with M_RESIDUAL_F32=1 and refuses it with M_EXACT=1.
Off by default: the default build's shaders (M, L, HDR and LDR) and the
exact build's are byte-identical to the previous ones.
Against the default build, final RGB, peak 1, 1280x720 -> 1440p: six smooth
temporal frames M 43.3 - 45.9 dB (L 44.6 - 49.2), at most 1.5 off; four
frames of the noise stress input M 17 - 18 dB (L 19 - 22). The exact build is
as far from the default (M 43.2 - 44.6 dB, L 44.5 - 47.0; noise M 16.7 - 17.9,
L 19 - 20) and as far from this one (M 43.4 - 44.8, L 44.6 - 47.0): no
further from NVIDIA's arithmetic than the default.
RX 9070 XT, d4r-m 720p -> 1440p, interleaved: M 1521 -> 1410 us (network
953 -> 841), L 2195 -> 2077 us (network 944 -> 829).
Signed-off-by: itchyfeetleech <[email protected]>
exposure_f.comp ran NGX's auto exposure in two passes: the 16x16 blocks wrote
their fixed-point luma sums, then a single workgroup added them after a
barrier and finished (11 us of a 25 us stage). PASS 2 does what NVIDIA's
kernel does: each block adds its sum to a 64-bit total with an atomic add
and counts itself in with an acquire-release add; the last block reads the
total, finishes and leaves both words zero for the next frame. The total is
an integer, the same in any order, so the exposure image and the values are
the two passes' bit for bit. compile_rr2.py builds exposure_f2.spv next to
the two passes' shaders (the block sum and the finish are shared functions
now; their arithmetic is unchanged).
64-bit buffer atomics are a device feature (shaderBufferInt64Atomics), so
RModel takes whether the device has it enabled (default no) and preset F
uses the one pass only then and only with a model that has exposure_f2.spv;
otherwise the two passes as before. vkd3d-proton creates its device with
every feature the GPU reports except a list it turns off, which does not
include this one (it backs D3D12's 64-bit atomics with it); the shim reads
the device's features through the interop interface (GetDeviceFeatures) and
logs the result. d4r-rr enables every feature the GPU has, and
D4R_RR_TEST_NO_INT64_ATOMICS=1 turns this one off to run the two passes.
Ray Reconstruction never runs on the native Vulkan frontend's device.
Every image of every frame byte-identical to the previous build (1280x720
-> 1440p, 1114x626 -> 1080p, 960x540 -> 1080p, the stress inputs, with
D4R_RR_TEST_ROBUST2=1, at levels 0 and 3, with D4R_RR2_SPLIT=1), and so is
the two-pass fallback of the new build; presets D and E unchanged. Controls:
the last block finishing with twice the total changes 64 of the 90 images of
the 1280x720 sequence (and nothing under the fallback), finishing without
its own block's sum 58 of 90.
RX 9070 XT, d4r-rr 720p -> 1440p, interleaved: exposure 25.2 -> 14.9 us,
frame 3.536 -> 3.526 ms (the fallback 25.1 us).
Signed-off-by: itchyfeetleech <[email protected]>
layer_m.comp's L expansion (KIND 4) wrote a window's block output to shared
memory and ran the per-pixel head after a workgroup barrier, both inside the
windows' loop, so it could not walk two windows per wave (#error for KIND
>= 3). Every window now writes its output first and the head runs once after
the barrier; L's input stage (KIND 3) gathers its features once, before its
windows' loop, the same way. At one window per wave RADV emits the same
machine code for both stages as before. WPW > 2 stays an error: the head and
the gather need the block's 64 pixels on 64 invocations.
compile_m.py builds dec0_l (and dec0_l_planes) with two windows per wave,
which load each weight tile once for both: 96 -> 216 vector registers, 14 ->
7 waves per SIMD. Not under M_EXACT=1, like the network layers (it would gain
7 us there, 516 -> 509); M_DEFS_DEC0L=-DWPW=1 builds the previous layout. The
input stage at two windows per wave is identical too but slower (452 -> 465
us; 144 -> 256 registers, 10 -> 5 waves), so it stays at one.
Every output frame byte-identical (L, HDR and LDR, 1280x720 -> 1440p,
1114x626 -> 1080p, 1920x1080 -> 1440p, the stress inputs) and so is
everything D4R_M_DUMP writes - with the new default, with both stages at one
window and at two, and in the exact build (one window, and the expansion at
two). The windows' outputs swapped in the head's staging changes every frame.
Preset M's shaders are unchanged.
RX 9070 XT, d4r-m L 720p -> 1440p, interleaved: expansion 383 -> 366 us
(1114x626 -> 1080p: 342 -> 326), frame 2205 -> 2191 us.
Signed-off-by: itchyfeetleech <[email protected]>
down_m.comp (presets M and L) unpacked the block's 16x100 source texels into
a shared tile, waited for it, filtered the rows from there and waited again.
Each invocation of the horizontal pass now loads the ten packed texels of
four output columns of one source row straight into registers and filters
them (200 such items for the block's 512 invocations): no shared source tile
(12.5 KiB) and one barrier fewer. 15 -> 5 KiB of shared memory, 36 -> 17
shared-memory instructions, 36 -> 48 vector registers (32 waves as before).
An output column's parity stays a run-time value (gl_NumWorkGroups.z - 1
added, the dispatch's z count is 1): with constant weights the compiler
shares products between neighbouring filters and splits their fused
multiply-adds, and 30% of the output pixels change (62 dB) - that build is
the positive control. ACO now unpacks with a fused multiply-convert
(v_fma_mix*_f16: one rounding instead of f32, then binary16), which gives
the same value for each of the 2048 / 1024 codes of a channel (checked
exhaustively, HDR and LDR constants).
Every output frame byte-identical (M and L, HDR and LDR, and the RGB10
output variant bound in the plain one's place; 1280x720 -> 1440p, 1114x626
-> 1080p, 1920x1080 -> 1440p, the stress inputs). Only down_m.spv and
down_m_rgb10.spv change.
RX 9070 XT, d4r-m, interleaved, downsample stage: 720p -> 1440p 102 -> 91 us
(L; M 117 -> 113), 1114x626 -> 1080p 62 -> 47 (L 61 -> 47); noise (the stress
inputs, whose output does not compress) unchanged, 144 -> 144 (L 139 -> 138).
Frame (L) 2213 -> 2202 us and 1963 -> 1951. Two or eight columns per
invocation instead of four: 92 / 93 us.
Signed-off-by: itchyfeetleech <[email protected]>
post_m.comp's invocations own a vertical pixel pair and ran the 3x3 (L 4x4)
Gaussian taps once per row, reading the three shared tile entries of every
tap twice. The two rows have the same column and texels and differ only in
dy, so both are now accumulated in one loop: one set of tile reads per tap,
dy, the exponent and the third accumulator as binary16 pairs (element 0 the
even row), and every operation of a row the one it had on its own, lane by
lane. The odd row keeps its own-cell residual rounding.
Every output frame byte-identical (M and L, HDR and LDR, the three tile
tiers: 1280x720 -> 1440p, 1114x626 -> 1080p, 1920x1080 -> 1440p, and the
stress inputs), and so is everything D4R_M_DUMP writes. Controls that must
differ: the odd row's weight sum times 1.01 (every frame of every input), the
rows' third accumulators swapped (every frame; in the dump only the packed
image, as g.z only enters it), the odd row's residual cast once (1114x626 ->
1080p, the one input where the rows' cells differ). Shader: 64 -> 37 shared
memory reads, 2105 -> 1969 instructions, 60 vector registers as before.
RX 9070 XT, d4r-m 720p -> 1440p, interleaved, reconstruction stage: 287 ->
265 us (L 355 -> 320), compact tier 193 -> 177 (L 244 -> 223), random motion
360 -> 347 (L 400 -> 367), 15x15 tier at 1920x1080 -> 1440p 424 -> 423 (L 427
-> 421). On the uniform-motion frames M's downsample after it measures 105 ->
117 us with the same shader (L's does not move), so the frame gains 7 us there
(1527 -> 1520), L 36 (2249 -> 2212).
Signed-off-by: itchyfeetleech <[email protected]>
post_m.comp (presets M and L) blends the history along the two most likely of
three motion candidates and sampled it once per candidate (five bilinear
taps; L also expands each sample to linear light). Where the motion is
uniform the two candidates usually have the same vector: the same position,
so the same bicubic sample or the same fallback colour (a NaN vector never
compares equal, +0 and -0 give the same position). That case now takes the
first candidate's value.
Every output frame byte-identical (M and L, HDR and LDR; 1280x720 -> 1440p,
1114x626 -> 1080p for the compact tile tier, 1920x1080 -> 1440p for the 15x15
tier, the stress inputs), and so is everything D4R_M_DUMP writes, the
history, half history and packed image included. Taking 0.99 times the first
sample there instead changes every frame of every input, the reset frames
too. Only post_m*.spv / post_l*.spv change.
RX 9070 XT, d4r-m 720p -> 1440p, interleaved, reconstruction stage:
uniform motion 325 -> 288 us (L 401 -> 354), compact tier at 1114x626 ->
1080p 219 -> 193 (L 275 -> 244); random motion unchanged (377 -> 374,
L 404 -> 401). Frame 1570 -> 1541 us (L 2299 -> 2249) on the uniform-motion
frames.
Signed-off-by: itchyfeetleech <[email protected]>
d4r-m's D4R_M_DUMP now also writes what the reconstruction (post_m.comp)
writes: the history (hist, RGBA16F at the reconstruction resolution), its
half-resolution mean (half, RGBA32F) and the packed 11-11-10 image the
downsample reads (packed). The presented image is the packed one filtered and
rounded again, so a change in the history shows up there a frame later, if at
all; the dump shows it in the frame it happens.
Signed-off-by: itchyfeetleech <[email protected]>
ptx2rr.py's tanh_ocml (tanh.approx.f32; only preset F's dec0_1 has it) ran
every fused operation through f64, which this GPU runs at a small fraction of
the f32 rate. They are f32 fma now, with two exceptions that keep every result:
- exp's error term fma(w, c, -ph) next to its own product ph = w * c comes out
of the driver as that product and a sum, exactly 0, even with precise or
opaque operands. It is Dekker's exact product error: w split into halves of
12 bits (w * 4097), log2(e) into 1.4423828125 + 0.0003122091293334961, every
partial product exact.
- the polynomial below 0.625 stays in f64: the driver always folded the f32
rounding between its four nested f64 steps away (f2f64(f2f32(x)) -> x, the
conversions are not NoContraction; seen in the NIR), so the old code
computed it in f64 with one rounding at the end. A true f32 polynomial
rounds 24,836 arguments one f32 step differently (2 in binary16).
A NaN argument keeps its payload, quieted and positive, as the f64 conversion
left it.
A GPU probe of the old against the new function: identical on all 2^32
arguments, NaN payloads included (with a plain fma for the error term instead:
3,976,308 differ, 490 in binary16). Only dec0_1.spv changes, at every level and
with D4R_RR2_SPLIT=1; presets D and E have no tanh.approx.f32 and their modules
are byte-identical. Every image of every frame byte-identical to the previous
model at levels 0 to 3 (1280x720 -> 1440p, a finite stress sequence with random
motion, a reset and a moving camera, and at level 3 also 1114x626 -> 1080p, the
NaN / Inf stress inputs and D4R_RR_TEST_ROBUST2=1); a model with tanh's
constants perturbed differs in 50 of 90 images, so the comparison sees it.
RX 9070 XT, RADV 26.2.2, d4r-rr 720p -> 1440p, interleaved: dec0_1 475 ->
446 us, frame 3.568 -> 3.537 ms; exact build (D4R_RR_RELAXED=0) 4.411 ->
4.388 ms. The polynomial in f32 as well would be 419 us.
Signed-off-by: itchyfeetleech <[email protected]>
d4r-m's D4R_M_DUMP wrote the network's input (tokens) and output (head); it now
also writes skip1, merged1, skip2, merged2, tubeA, tubeB and dec2, so that a
difference between two builds can be found at the first layer it appears.
Signed-off-by: itchyfeetleech <[email protected]>
Timing only: with D4R_ENGINE_M_LAYER_STAMPS=1 the runtime writes a timestamp
after each of the ten network layers (queries first + 7 on) and d4r-m prints
the per-layer medians. RX 9070 XT, 1280x720 -> 1440p: enc1 210, enc2 115,
tube 6 x 50, dec2 114, dec1 209 us.
Signed-off-by: itchyfeetleech <[email protected]>
layer_m.comp's V tiles (VSH, 4 KiB, per wave and head, accessed only as
matrices and only during the attention) had their own shared memory. Shared
memory caps how many waves this GPU runs, and ACO gives a shader the
registers that many waves leave, so the network layers ran at 3 - 6 waves
per SIMD with registers to spare.
VSH now takes the place of a buffer that is dead during the attention:
- the merge rows NB (enc1, enc2, L's input stage), written after it;
- the expansion NEX (dec1, dec2), read before it;
- HO (L's expansion stage), written after it.
One barrier each before the buffer's own use (none was needed while the
buffers were apart). The tube keeps its own 4 KiB.
| layer | shared memory | vector registers | waves per SIMD |
| enc1 | 13 -> 9 KiB | 256 -> 216 | 4 -> 7 |
| enc2 | 17 -> 13 KiB | 256 | 3 -> 4 |
| dec2 | 13 -> 9 KiB | 256 -> 240 | 4 -> 6 |
| dec1 | 10 -> 6 KiB | 240 -> 192 | 6 -> 8 |
| L input | 16 -> 12 KiB | 192 -> 144 | 8 -> 10 |
| L expansion | 13 -> 9 KiB | 192 -> 96 | 8 -> 14 |
Output byte-identical (M and L, six temporal frames at 1280x720 -> 1440p
and 1114x626 -> 1080p). RX 9070 XT, d4r-m 720p -> 1440p, with the previous
commit: M 1583 -> 1566 us (network 967 -> 951), L 2349 -> 2293 us (input
479 -> 453, expansion 401 -> 382). The tube on one window per wave instead
of two (192 registers, 8 waves) is 9 % slower and stays as it is.
Signed-off-by: itchyfeetleech <[email protected]>
layer_m.comp (M / L, M_RELAXED) converts to FP8 with saturatedConvertEXT,
which RADV lowers as a NaN-preserving clamp per element and the conversion.
As in engine/rr/rr_exact.glsl (FINITE), a value that is never infinite can be
written as "an infinity becomes NaN, then saturate", which RADV turns into the
hardware conversion with FP16_OVFL (f2e4m3fn_satfn, Mesa >= 25.2): the same
result for every finite value and NaN.
Only two sources are provably finite and take it (SATF2_ / MK8_F8F):
- the attention's f32 sums of FP8 products (o);
- the normalised tokens (H1N): the norm sums the squares of the very values
it scales, so an infinite channel makes the reciprocal 0 and the product
NaN, never infinite.
The binary16 accumulators (q, the MLP, the expansion, the residual) can
overflow to infinity, or carry an infinite input pixel, and keep the clamp.
Per network shader 352 -> 64 clamps (one 384 -> 160), 3-4 % fewer
instructions. Output byte-identical (M and L, six temporal frames at
1280x720 -> 1440p and 1114x626 -> 1080p). RX 9070 XT, d4r-m 720p -> 1440p:
M unchanged (1579 / 1583 us, its network is not issue-bound), L 2348 ->
2329 us (input 479 -> 471, expansion 400 -> 386).
Signed-off-by: itchyfeetleech <[email protected]>
dec0_1's translated output tail ran on wave 0 while the block's other three
waves had finished. It is a prologue (y = r + MLP * s2 and the shuffles that
give each lane its two pixels) followed by the same per-pixel code twice.
gen_rr2_enc0.py --tail-waves N gives each of N waves its own copy of the
tail with only its N-th of the stores (in order: the first pixel's six, then
the second's), and the compiler drops what a copy's stores do not need.
Every stored value comes from the same instructions on the same values as on
one wave. With one window per workgroup, the window index no longer adds
gl_SubgroupID (it was 0 for the only valid wave).
compile_rr2.py uses two waves (D4R_RR2_TAIL_WAVES=1 for one): 120 -> 96
vector registers, 12 -> 16 waves per SIMD; RX 9070 XT, 720p -> 1440p:
dec0_1 565 -> 474 us. Four waves, splitting each pixel's stores, is slower
(529 us). Every image byte-identical on the replay inputs (also robustness2,
no robust access and the split gather build).
Signed-off-by: itchyfeetleech <[email protected]>
- ptx2rr.py fetch0 (the translation's bounds-checked texel fetch): one
unsigned comparison per axis instead of two signed ones; a negative
coordinate is above every size. enc0's gather fetches 102 times: 231
instructions fewer, scalar spills 200 -> 176.
- The output passes (post, down, downp, pooled) also go through
spv_exact_convert.py now and take ptx2rr.py --exact-convert's single f32
guard on binary16 conversions, as the hybrid stages do. Their ISA already
uses v_fma_mix*_f16 for plain conversions, so the check is the whole
instruction mix: only v_and_or_b32 / v_or / v_perm / shifts go (post -16
VALU, down -9, downp -73); every v_fma_f32 / v_mul_f32 / v_add_f32 /
conversion / v_exp / v_log count is unchanged.
Every image byte-identical on the replay inputs (also robustness2 and the
split gather build). RX 9070 XT, 720p -> 1440p: enc0 745 -> 738 us, output
673 -> 665 us.
Signed-off-by: itchyfeetleech <[email protected]>
RADV lowers saturatedConvertEXT to FP8 as a NaN-preserving clamp per element
(v_minimummaximum_f32) followed by v_cvt_pk_fp8_f32, because the hardware's
FP16_OVFL saturation turns infinities into NaN instead of +-448. Run over all
2^32 f32 inputs on an RX 9070 XT, FP16_OVFL gives the clamp's result for
every finite value and NaN; only +-Inf differ.
The f32 values the native stages convert are never infinite (sums of FP8
products and binary16 biases, far below 3.4e38). Writing the conversion as
"an infinity becomes NaN, then saturate" (FINITE in rr_exact.glsl) makes it
the pattern nir_opt_algebraic turns into f2e4m3fn_satfn (vkd3d-proton's,
Mesa >= 25.2, the same release that added the FP8 conversions): the
hardware conversion with FP16_OVFL and no clamp. RR_SAT_CLAMP=1 builds the
old form.
168 - 232 fewer instructions per network stage (enc0 960 -> 128 clamps).
Every image byte-identical on the replay inputs (also robustness2). RX 9070
XT, 720p -> 1440p: frame 3.92 -> 3.79 ms, every network stage faster
(dec0_1 607 -> 576 us, enc0 752 -> 727, enc1 262 -> 247).
Signed-off-by: itchyfeetleech <[email protected]>
ptx2rr.py guards every cvt.rn.f16.f32 with two opaque zeros: on the f32 bits
(against the fused multiply-convert, v_fma_mix*_f16) and on the binary16
bits (against RADV folding float(float16_t(x))). The hybrid stages' modules
(enc0, dec0_1) also go through spv_exact_convert.py, whose NoContraction on
every conversion already prevents the fold, so with --exact-convert only the
f32 OR is emitted.
Checked in RADV's ISA: the same v_cvt_f16_f32 / v_cvt_f32_f16 counts as
before and no v_fma_mix*_f16 (dropping the f32 OR as well brings
v_fma_mixlo_f16 back, so that one stays). Every image byte-identical on the
replay inputs, the split gather build (D4R_RR2_SPLIT=1) as well. 224 / 153
fewer instructions; RX 9070 XT, 720p -> 1440p: enc0 747 -> 729 us, dec0_1
598 -> 592 us.
Signed-off-by: itchyfeetleech <[email protected]>
ACO sizes a shader's registers to the waves its shared memory leaves room
for, so stages that declare less shared memory also get fewer registers and
more waves. Three stages hold buffers whose lifetimes do not overlap:
- Encoder 0 at D4R_RR_RELAXED=3: with the one-wave block the gather no
longer needs a pass of its own. The generated shader runs gather, block
and tail in one 32-thread group and hands the features over in shared
memory that the block's XT and KVS reuse (rr2_w.comp RR2_XF_SHARED). No
gather pass, no record in the arena (36 MB of it lay past the arena at
720p). D4R_RR2_SPLIT=1 keeps the pass.
- enc1: the merge input (GT) is in registers before XT or KVS is written:
17 -> 9 KiB, 240 -> 144 vector registers, 6 -> 10 waves per SIMD.
- dec0_1: r and the MLP sum for the tail are written after the block is done
with XT and KVS, as binary16 pairs: 14 -> 8 KiB, 192 -> 120 registers,
8 -> 12 waves per SIMD.
Also D4R_ENGINE_RR_STAGE_STAMPS=1: a timestamp after every network stage and
output group, printed per stage by d4r-rr.
Every image of six temporal frames byte-identical to the previous model
(1280x720 -> 1440p, 1114x626 -> 1080p, 853x480 -> 1440p, robustness2). RX
9070 XT, RADV, 720p -> 1440p: frame 4.09 -> 4.00 ms (enc0 798 -> 772 us,
enc1 286 -> 266, dec0_1 660 -> 623). Other stages' SPIR-V is unchanged.
Signed-off-by: itchyfeetleech <[email protected]>
Native Vulkan NGX callers now get d4r's own network for presets K, M and L,
recorded straight into the caller's command buffer on the game's VkDevice with
the same GameUpscaler/GameUpscalerM adapters the D3D12 path uses through
vkd3d-proton. No CPU staging, CUDA evaluation or host wait. D4R_VULKAN_ENGINE=0
keeps the staging path, and anything the engine does not cover still goes there
with a logged reason.
- Inputs are sampled through the caller's views (SHADER_READ_ONLY_OPTIMAL, or
GENERAL with D4R_VULKAN_INPUT_GENERAL=1); depth/stencil views get a depth-only
view. The output must be an RGBA16F (or RGB10A2 with an RGB10 model) storage
image the engine writes directly, since the resource contract gives STORAGE
usage only.
- Every recording ends with an event; engine objects of a released feature are
destroyed once all recorded events fired, or at shutdown.
- GetFeatureDeviceExtensionRequirements reports VK_KHR_cooperative_matrix and
VK_EXT_shader_float8 where available. It applies d4r.ini first: games ask
before NGX init, and engine_requested() would otherwise cache "off".
- The engine accepts R16G16_SNORM motion vectors (Enshrouded).
- Engine model loaders accept a native device (VulkanInterop::native).
- Harness: D4R_HARNESS_ENGINE_DEVICE=1 (1.3 device with the engine's
features), D4R_HARNESS_ALLOW_BLACK=1 (staging K's black reset frame).
Harness vs the staging path (RX 9070, GE-Proton11-7, 640x360 -> 1280x720):
K 99.6 % bit-identical, rest within one half-float ulp; M 52.7 dB, L 54.3 dB
PSNR; dynamic, recreate and discard pass for K and M. In game, Enshrouded runs
preset M on this path (docs/vulkan.md, SUPPORTED_GAMES.md).
Signed-off-by: itchyfeetleech <[email protected]>
itchyfeetleech