Exactness needs a named boundary.
OpenDLSS-NR says its Vulkan implementation matches DLSS-NR build 310.8.0 at all 75 comparable block and encoder-transition boundaries. Its parity checker treats a signed-zero change as failure, requires every boundary to have a reference or an omission reason, and compares the production schedule with a barrier-heavy schedule.[1]
That is a precise contract. The repository also says the CPU reference does not cover the expert feed-forward network, the 512-channel split block, or the global transformer. Those sections rely on two GPU routes matching native captures at block boundaries. The evidence remains strong, but the diagnostic depth changes inside the graph.
"Bit-exact" answers a byte question. It does not answer every integration question.
The missing files are part of the result.
The repository supplies code, documentation, build scripts, and an MIT license. It does not supply weights or parity fixtures. The model loader expects a manifest with stage hashes and tensor offsets. The parity tool expects recorded references that account for the whole declared check. Without those files, a fresh clone cannot reproduce the headline claim.[2]
The license boundary is explicit. The project license covers the repository. Its notice says the repository contains no NVIDIA software, weights, or headers. It grants no rights to model data. That distinction belongs beside the build command, not in a footnote after adoption.
A frame is more than one graph pass.
The command-line tool runs single frames without history. The demo adds the temporal loop. It builds a display proxy, records motion, reprojects the previous output, samples history, uses the network's blend logit, and writes the next history image. The frame document says this surrounding pipeline is as important to matching output as the network itself.[3]
This is the integration trap. A team can reproduce the graph and still ship different pixels because motion, padding, history publication, renderer synchronization, or display conversion differs. Test the graph to debug arithmetic. Test moving scenes to judge the product.
The fast route is hardware-specific.
The native build requires Windows, an NVIDIA Ada or newer GPU, and named Vulkan extensions. One fast route launches CUDA kernels inside a Vulkan command buffer. Khronos describes VK_NV_cuda_kernel_launch as an NVIDIA extension for loading CUDA fat binaries and launching CUDA kernels from Vulkan.[4]
The repository's WebGPU port matters because it separates graph identity from one fast implementation. The authors report the same reference bytes through a slower route without tensor cores or FP8. That is portability evidence for the specification. It is not performance parity or proof that another renderer has the same frame contract.