# OpenDLSS-NR: a Vulkan reimplementation of NVIDIA's DLSS 5 neural rendering > OpenDLSS-NR is an open source reimplementation of NVIDIA's DLSS 5 Generative Neural Rendering network that runs on Vulkan and is stated to be bit-exact against the original, with a second browser port that reaches the same bytes without tensor cores. It ships no weights, targets Windows with Ada class hardware, and implements only one of NVIDIA's two networks. **maanHimself/OpenDLSS-NR** — A Vulkan reimplementation of NVIDIA's DLSS 5 Neural Rendering network, bit-exact against the original. - Repository: https://github.com/maanHimself/OpenDLSS-NR - Stars: 1,017 · Forks: 89 - Language: JavaScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/maanhimself-opendlss-nr ## A generative re-renderer, not an upscaler The repository describes itself as a Vulkan reimplementation of NVIDIA's DLSS 5 Neural Rendering network, bit-exact against the original, and the distinction that matters is stated in the same breath: input and output are the same resolution, and it is not an upscaler. The network re-renders a frame the engine has already drawn. It generates detail from injected noise and adjusts tone, structure and skin under a style setting, in the generative sense NVIDIA uses that term. Architecturally it is a U-net of shifted-window transformer blocks with a global ViT at the bottom, described as 71 blocks over six pooling levels, with FP8 (E4M3) activations and FP16 accumulation, and 141 MiB of weights. One rendered frame goes in: a low dynamic range proxy of it, three lanes of Gaussian noise, the previous frame's output reprojected, and five conditioning scalars. Four f32 channels per pixel come out, an RGB residual and a temporal blend logit. The full graph is written out in docs/network.md, and the project points to NVIDIA's own report on DLSS 5 Generative Neural Rendering as the reference description. So the audience is not a gamer looking for a frame rate win. It is someone who needs to know what the network computes, needs the same numbers NVIDIA's implementation produces, or wants the model running in an environment NVIDIA does not ship. The claim of bit-exactness extends past the final image: the project states that all 75 block boundaries match byte for byte, not just the output. ## The manifest.json contract and the refusal of other models The weights are not in the repository and are not produced by it. That is stated plainly: you supply the weights as a model directory in a described layout. The host class nr::Model reads manifest.json, which holds a stages array where each entry has an id, a file path relative to the directory, a packedByteLength and a sha256, plus a tensors array where each entry carries name, block, layer, parameter, stage, stageOffset and byteLength. Stage files hold the E4M3 weights as packed bytes, and the host re-lays them out into the matrix forms the kernels consume, in src/nr_model.cpp. The strictness of that contract is the point. The graph is the 71-block network of build 310.8.0 and nothing else, and a model with a different block count is refused at load. The same 71-block Swin and ViT network is what the WebGPU port targets, which is why the two implementations can be compared against the same captures. This creates the practical constraint for any adopter. The project supplies an execution engine and a weight format, not a model. Whether the weights you need are legally available to you, and whether they match this exact block layout, is a gate that sits in front of everything else. Nothing in the repository produces such a directory, and the fixtures used for verification are recorded captures of the original that are also not part of the repository, so the parity and verify commands need directories you must obtain elsewhere. ## Two kernel routes: hand written GLSL and generated PTX The host side is C++20 under src/ and handles the Vulkan context, model loading and weight re-layout, kernel wrappers, the network graph, a CPU reference of the arithmetic, and the dlss5vk tool. The compute side is split in two, and the split is the most interesting engineering decision in the project. The GLSL kernels in shaders/ are the reference route. They are described as exact and complete on their own: cooperative-matrix FP8 GEMMs, a fused 32-channel block, fused QKV and window attention, an expert MLP, global attention and elementwise ops. The PTX kernels in scripts/ptx/ are Python generators that emit PTX for the fast route, using mma.sync E4M3 with f16 accumulation, cp.async rings, barrier-free chaining through device counters, split-K GEMMs and streamed global attention. The generated PTX lands in build/ptx during the build. Two routes with different capabilities means the project can be checked against itself. The GLSL path is the semantics, the PTX path is an optimisation that has to reproduce them. The dlss5vk verify command exists to bisect that: a block-0 kernel-by-kernel bisect against a fixture, which is how you find which kernel in a chain diverges. The project also ships a Python test for the PTX fast divider that runs over every n below 2^24, an unusual kind of check to include and a hint at how much of the failure surface lives in integer arithmetic tricks rather than in the network structure. ## Building on Windows and running the first bench The build is a set of PowerShell scripts, and the tooling is portable enough that no Vulkan SDK install is required. The scripts etch_tools.ps1 step downloads glslang 16.6.0, Vulkan-Headers v1.4.363, volk at pinned tags, CMake 3.31 and Ninja 1.13 into a git-ignored tools directory, and passing -Npm also installs the scene converter's modules into tools\gltf. The build sequence as given in the project is: ```bash powershell -File scripts\fetch_tools.ps1 [-Npm] # once: tools\ (glslang, Vulkan-Headers, volk, CMake, Ninja) powershell -File scripts\build.ps1 # shaders, PTX, build\dlss5vk.exe powershell -File scripts\fetch_filament.ps1 # once, for the demo: third_party\filament (+ the patch) powershell -File scripts\build_filament.ps1 # once, for the demo: third_party\filament-install powershell -File scripts\build_demo.ps1 # build\demo\dlss5-demo.exe ``` The first two produce the shaders, the PTX and the build\dlss5vk.exe tool; the remaining three are for the demo, fetching Filament v1.77.0 and its patch, building it, then building the demo. Requirements are Windows with Visual Studio 2022 or later on the C++ x64 toolset, git, Python 3 for the PTX generators, and Node.js with npm and Pillow for the scene converter. The model directory is resolved from --model , otherwise the DLSS5VK_MODEL environment variable, otherwise models\nr next to the README. With a tool and a model directory in hand, the command line surface of the tool is short and worth reading: ```bash build\dlss5vk.exe bench --model --width 768 --height 768 build\dlss5vk.exe profile --model --width 768 --height 768 # per-dispatch timings build\dlss5vk.exe parity --model --fixture # bit-exactness against a fixture build\dlss5vk.exe verify --model --fixture # block-0 kernel-by-kernel bisect ``` bench measures, profile gives per-dispatch timings, parity checks bit-exactness against a fixture and verify does the kernel by kernel bisect. ## Performance figures and the caveat that qualifies them The project publishes a performance table and, importantly, publishes the caveat that goes with it. The figures are for an RTX 4070 SUPER, whole network per frame, minimum over 40 frames, with 241 dispatches at every resolution. At 768x768 the time is 2.8 ms, at 1920x1080 it is 7.8 ms, at 2560x1440 it is 12.6 ms, and at 3840x2160 it is 29.3 ms. The caveat matters more than the numbers. The GPU alternates between two clock states under sustained load, so medians run a few percent higher, and the instruction is to compare minima. That is an honest way to report a figure on a consumer card, and it also tells you the numbers do not transfer to a laptop GPU or a datacenter part without remeasuring. What this table is not is a comparison. There is no NVIDIA figure to sit beside it in the repository, so a reader can see the cost of the network in isolation but not the cost relative to the original implementation. For an engineer deciding whether the approach is viable in a shipping product, that gap has to be closed elsewhere, and the project does not help close it. ## The WebGPU port as a specification rather than an implementation ports/browser-webgpu/ is a second, independent implementation of the same network. The same bytes in a browser, with no tensor cores and no FP8. The project is explicit about what that means: no tensor core, no FP8, no fusion between blocks and no chaining, and the exactness lives in the specification rather than in the hardware. That is a notable claim to make in either direction. It means the numeric result does not depend on the hardware path, which is the ideal outcome for a network that claims bit-exactness, and it simultaneously means the browser port is much slower. The project gives a figure of 72 ms at 512x512 for the WebGPU route against 2.7 ms for the native route, which is the cost of dropping the specialised hardware. The demo sits on the other side of this design. It places the network inside a Filament frame, with Filament patched for per-object motion vectors and a Vulkan interop hook, glTF scenes through gltfio and ImGui controls. The README notes that the temporal path is implemented, but in the demo: the network's history input lanes and its per-pixel blend logit drive a reprojected feedback loop described in docs/frame.md. The dlss5vk tool itself runs single frames with no history, which is what the reference captures were made with. If your interest is the temporal behaviour rather than the arithmetic, the demo is the part that covers it and the tool is not. ## What is absent: DLSS-SR, the weights, and the fixtures The gaps are stated as plainly as the features. Not implemented is DLSS-SR, which the project notes is a different network. So the repository covers one of NVIDIA's two DLSS 5 components, and anyone whose goal is super resolution will find nothing here. The other two gaps are legal and practical rather than technical. The weights are not here and nothing in the repository produces them, and the parity fixtures, which are recorded captures of the original, are not part of the repository either. The licence field on the repository says MIT, and the Filament component it embeds for the demo is credited as Apache-2.0, with a NOTICE file and a third_party directory at the top level. The MIT terms cover the code; they say nothing about the model weights, whose provenance is a separate question you have to answer yourself before running this on anything. On maintenance, the last push was on 2026-09-21 and the repository has no GitHub releases, so there is no published version to pin. The upgrade path is therefore whatever the main branch gives you on the day you clone, and the absence of tagged releases means you have no stable reference point to diff against when something changes. ## Conclusion OpenDLSS-NR suits engineers who need to read, reproduce or extend a DLSS 5 neural rendering network outside NVIDIA's stack, and who already have Ada class hardware, a Windows toolchain and a legal model directory to hand. It is the wrong choice for shipping a game, for DLSS-SR or super resolution work, and for anyone who needs the temporal history path outside the demo. Verify first that your model directory matches the manifest.json contract with a 71 block count, that a driver exposes VK_KHR_cooperative_matrix and the three other required extensions, and that your build machine can absorb the roughly 6 GB Filament build tree before starting. ## FAQ ### What is OpenDLSS-NR and what does it reimplement? It is a Vulkan reimplementation of NVIDIA's DLSS 5 Neural Rendering network, described as bit-exact against the original. The network is a 71-block U-net of shifted-window transformer blocks with a global ViT, taking one rendered frame plus noise and producing four f32 channels per pixel. ### Where do I get the model weights for OpenDLSS-NR? You supply them. The project expects a model directory with a manifest.json describing stages and tensors, and it states that nothing in the repository produces such a directory. A model whose block count differs from 71 is refused at load. ### What hardware does OpenDLSS-NR need? Windows with an NVIDIA Ada or newer GPU and a driver exposing VK_KHR_cooperative_matrix, VK_NV_cooperative_matrix2, VK_EXT_shader_float8 and VK_NV_cuda_kernel_launch. Visual Studio 2022 or later, git, Python 3, and Node.js with npm and Pillow are also listed. ### How do I build OpenDLSS-NR on Windows? Run powershell -File scripts\fetch_tools.ps1 to download glslang, Vulkan-Headers, volk, CMake and Ninja, then powershell -File scripts\build.ps1 to produce the shaders, the PTX and the dlss5vk tool. No Vulkan SDK install is needed. ### Does OpenDLSS-NR work in a browser? Yes, through ports/browser-webgpu/, a second implementation of the same network with no tensor cores and no FP8. The project states 72 ms at 512x512 for that route against 2.7 ms for the native one. ### Is DLSS-SR included in OpenDLSS-NR? No. The project states that DLSS-SR is not implemented because it is a different network. Only the generative neural rendering path is covered. ## Sources - [Issues](https://github.com/maanHimself/OpenDLSS-NR/issues) - [License: MIT](https://github.com/maanHimself/OpenDLSS-NR/blob/main/LICENSE) - [maanHimself/OpenDLSS-NR on GitHub](https://github.com/maanHimself/OpenDLSS-NR) - [README](https://github.com/maanHimself/OpenDLSS-NR/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/maanhimself-opendlss-nr