The bridge's other instrumentation - D4R_CUDA_LAUNCH_STATS with
D4R_CUDA_LAUNCH_DUMP_DIR - already dumps every allocation, surface object and
texture object named in a launch's packed argument buffer, after the launch has
finished. That is enough to check one reimplemented kernel on its own: the
translated kernel's surface files are its output, and a native replacement has
to reproduce them.
What was missing was the comparison. compare_launch_dump.py keys the files by
kernel, argument offset, kind, shape and format rather than by the global launch
sequence, so a replacement that adds launches of its own does not break the
alignment, and it reports the first differing byte per argument.
Verified end to end today: cuda_dldn_engine_swin_enc0_kernel's PTX module was
compiled offline with d4r_emit, served from a native directory (the bridge logs
`[d4r-native] "cuda_dldn_engine_swin_enc0_kernel" -> ...hsaco`), and its run is
byte-identical to the translated one across all 54 of its dumped arguments -
weight image, activation buffer, four output surfaces. That also shows the
offline build reproduces the loader's own compile exactly, which every native
denoiser layer will rest on.
docs/native-kernels.md gains the dump-and-diff step, which is the only way to
localise a mismatch to one of the eleven layers that sample textures and write
surfaces.
woutermans
708b158332