itchyfeetleech
9aa402e70f
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 (dlss 4 radeon)
want to run xess (xmx) on radeon? check out x4r!
d4r runs NVIDIA's official DLSS Super Resolution (nvngx_dlss.dll) and experimental Ray Reconstruction (nvngx_dlssd.dll) in Windows games on AMD Radeon GPUs under Linux and Proton. The game asks for DLSS as usual; the DLSS network runs on the AMD GPU through ZLUDA (CUDA on ROCm/HIP), with the heaviest kernels replaced by hand-written RDNA2, RDNA3 and RDNA4 code.
Supported DLSS models: DLSS 3 CNN (E), DLSS 4 transformer (K, default), and DLSS 4.5 transformer (M, plus L for Ultra Performance). Ray Reconstruction presets D, E and F are experimental (building). DLSS 5 is PURPOSELY not supported.
Proof of concept: d4r shows that DLSS can run on an AMD GPU, but it is not really that practical for everyday use yet. It depends on unreleased patches to ZLUDA and vkd3d-proton. See supported games for the tested games and models.
Not affiliated with NVIDIA or AMD.
To contact me my discord is ._ayo. or join the d4r discord server
Results
DLSS Ultra Performance demo video · more videos
Radeon RX 7700 XT (RDNA3, gfx1101), SILENT HILL Townfall at 2560×1440, every DLSS result is presented in the frame it belongs to (no added latency).
| Mode | DLSS 3 CNN (preset E) | DLSS 4 (preset K) | DLSS 4.5 (preset M) | FSR 4* |
|---|---|---|---|---|
| Quality (1705×960) | 71.7 fps | 67.9 | 49.3 | 76.0 |
| Balanced (1488×837) | 80.8 | 75.9 | 58.0 | 84.5 |
| Performance (1280×720) | 89.7 | 84.1 | 69.0 | 94.0 |
| Ultra Performance (853×480) | 89.1 | 95.5 | 92.2 | 107.3 |
* FSR 4 was measured on 2026-09-27, the DLSS columns on 2026-09-29, when the same machine ran about 2–4% slower overall. Native 2560×1440 without upscaling (the game's TSR at 100%) runs at 49.1 fps on the same walk. How the numbers were measured: docs/performance.md.
Switching models and FSR in game
Open OptiScaler's menu (Insert):
- DLSS model: under DLSS Settings, tick Render Presets Override, pick the preset (E, K, L or M) and press Apply Changes. Unticking it returns to
[DLSS] Modelind4r/d4r.ini. - FSR: set Upscaler (DX12) to FSR 3.X/4. RDNA3 and RDNA4 get FSR 4.1 (needs GE-Proton, which supplies AMD's FSR 4 library); other GPUs get FSR 3.1.
Both are on by default; [OptiScaler] FollowPresets and Fsr4 in d4r.ini turn them off.
Known issues
- In some games using some models native upscaling can show visible artifacting. For fidelity over speed, set
[Kernels] PreferAccuracy = trueind4r/d4r.ini(native kernel numerics).
GPU support
!WE ARE LOOKING FOR VIDEOS OF IT WORKING, IF YOU HAVE A MENTIONED HERE AND DOESNT HAVE A VIDEO PLEASE TAKE ONE!
| GPU | Chip | Native kernels | Runtime testing |
|---|---|---|---|
| RX 7700 XT, RX 7800 XT, RX 7700, Radeon PRO W7700 | gfx1101 | K, M, L (WMMA) | RX 7700 XT |
| RX 7900 GRE / XT / XTX, Radeon PRO W7800 / W7900 | gfx1100 | K, M, L (WMMA) | RX 7900 XTX: external video |
| RX 7600 / 7600 XT, RX 7650 GRE, RDNA3 integrated GPUs | gfx1102, gfx1103 | K, M, L (WMMA) | untested |
| RX 9070 XT / 9070 / 9070 GRE, Radeon AI PRO R9700 | gfx1201 | K, M, L (WMMA, native FP8) | RX 9070 XT: external video |
| RX 9060 XT / 9060 | gfx1200 | K, M, L (WMMA, native FP8) | compile only |
| RX 6000 series, Steam Deck, RDNA2 integrated GPUs | gfx1030–gfx1036 | K (software matrix products) | validated on RDNA3 only |
| RDNA1 and older | unsupported |
RDNA2 has no WMMA instructions: its K kernels do the same matrix products with v_dot2 and DPP broadcasts, bit-identical to the WMMA build. Running that RDNA2 path on an RX 7700 XT for testing, K took 3.6 ms per 1080p frame, against 46.8 ms fully translated (what RDNA2 had before); RDNA3 itself keeps WMMA (1.48 ms). E and K are the models to use there; M and L run fully translated. Kernels missing for a GPU fall back to ZLUDA and can be much slower. Details: docs/native-kernels.md.
How it works
game (D3D12) ──► OptiScaler ──► d4r nvngx.dll (NGX D3D12 API) ──► NVIDIA's NGX core + nvngx_dlss.dll (CUDA path)
▼
native RDNA kernels ◄── ZLUDA (PTX → AMDGPU) ◄── nvcuda.dll (Wine CUDA bridge)
The shim keeps the game's inputs and output in VRAM through vkd3d-proton's Vulkan interop; ZLUDA compiles NVIDIA's PTX and serves hand-written kernels in place of the heaviest ones. An optional native inference engine ([Engine]) runs K, L and M with d4r's own Vulkan shaders. Details: docs/architecture.md.
Install the release
- Extract
d4r-<version>.zipinto the folder that holds the game's main.exe(OptiScaler 0.9.4 asdxgi.dll, the d4r-patched vkd3d-proton, AMD's FSR files and thed4rfolder). - Run
bash install.shthere. It downloads NVIDIA's DLSS and NGX files from NVIDIA, checks their SHA-256 hashes and puts them ind4r/. Needs Bash, curl, sha256sum and 7-Zip; no sudo, ROCm not required. - In Steam, select GE-Proton 11 for the game and set the launch options
PROTON_FORCE_NVAPI=1 DXVK_NVAPI_GPU_ARCH=AD100 %command%.
When updating, replace d3d12.dll, d3d12core.dll and d4r/nvngx.dll together. Already using OptiScaler? The -asi zip adds d4r as a plugin (ASI guide). The full guide ships in the zip as D4R_README.txt.
Building from source
Linux with an RDNA2, RDNA3 or RDNA4 GPU, ROCm 7.2 with HIP and its clang, GE-Proton 11, a Rust toolchain, meson/ninja, winegcc, x86_64-w64-mingw32-g++, clang-cl and Python 3. The full sequence is in docs/building.md; scripts/package_release.sh builds the release zip.
| Path | Contents |
|---|---|
tools/ |
the NGX shim, the Wine CUDA bridge, a D3D12 DLSS harness, probes |
kernels/ |
native kernels (k/ DLSS 4, m/ DLSS 4.5, tex/ texture tails, common/ matrix layouts) and their tools |
engine/ |
the native K/L/M inference engine |
patches/ |
ZLUDA, vkd3d-proton and OptiScaler patches |
scripts/, config/, packaging/, docs/ |
build/launch scripts, the developer d4r.ini, release files, documentation |
Star History
License
GNU General Public License, version 3 only (GPL-3.0-only; see LICENSE). The patches in patches/ are offered under the licenses of the projects they modify: ZLUDA (Apache-2.0 or MIT) and vkd3d-proton (LGPL-2.1). See NOTICE. The downloaded NVIDIA files and the kernels built from NVIDIA's code are not covered by this license.