DLSS-NR on AMD, an unofficial tool that runs DLSS 5's neural rendering on AMD Radeon GPUs, rolled out major performance improvements in back-to-back updates released early on September 26 (Japan time). Developer Daniel Blanco reported a 23% improvement in Alpha 0.3.3 over the previous version, followed by a further 42% improvement in 0.4.0. Multiplying these two performance ratios together—assuming identical test conditions—works out to a 74.66% increase. A day later, on the 27th, version 0.4.1 was released with additional speed gains. Anyone trying this on Radeon hardware should understand not just these percentage gains, but also whether the AI runs before or after FSR upscaling, and how motion and color are handled.
What multiplying 23% and 42% actually tells you
Alpha 0.3.3 and 0.4.0 were both published on September 25 in UTC—which translates to 12:54 AM and 2:24 AM on September 26 in Japan time. The two releases were about 90 minutes apart.
Here's how the developer's stated comparisons break down for each version:
| Release | Release time (Japan time) | Developer-reported improvement | Comparison baseline |
|---|---|---|---|
| Alpha 0.3.3 | Sep 26, 0:54 | 23% | Alpha 0.3.2 |
| Alpha 0.4.0 | Sep 26, 2:24 | 42% | Alpha 0.3.3 |
If you chain v0.3.3's 23% and v0.4.0's 42% together—assuming they were measured against the same metric under identical conditions—you get a factor of 1.7466, or a 74.66% increase. This isn't a measured FPS figure, nor is it guaranteed across all GPUs.
The math is 1.23 × 1.42 = 1.7466. Rather than simply adding 23 and 42 together, the calculation treats it as one performance gain building on top of another, compounding from the 0.3.2 baseline. This isn't a comparison against a game running with DLSS NR disabled, nor against NVIDIA's official implementation. It also doesn't mean processing time dropped by 74.66%.
However, neither release's notes specify which games, GPUs, or resolutions were used for testing. It's also unclear whether "performance improvement" refers to overall game FPS or specifically to the neural processing step. So the roughly 74% figure should be read as a conditional calculation derived from linking together two published numbers—not as a benchmark you can expect to reproduce on your own Radeon setup.
Running before FSR, and its relationship to internal resolution
Blanco explains in the project's FAQ that DLSS-NR on AMD isn't a compatibility layer that simply runs NVIDIA's original execution code on Radeon hardware as-is. Instead, it's a reimplemented neural network execution system, with the GPU compute portion rewritten in HIP for AMD hardware and the memory layout and game integration rebuilt from scratch. This is the developer's own account of the implementation, and should be treated separately from any independent third-party verification of the underlying code.
The neural rendering process itself adds lighting and material detail to frames the game has already drawn. NVIDIA's official explanation also positions this as a feature that takes one frame as input and produces one frame as output—separate from Super Resolution, which increases resolution, and Frame Generation, which inserts new frames in between existing ones.
This distinction matters for understanding how the tool interacts with FSR. In 0.3.0, Blanco introduced a mode—enabled by default—that runs the neural processing step before FSR upscaling. When an image is rendered at a lower resolution and then scaled up, running the AI step before that upscaling reduces the number of pixels it has to process.
In other words, even when the final displayed resolution is identical, the size of the image the AI is actually computing on may not be. Comparing two FPS figures measured under different FSR quality modes or different processing orders can conflate the effect of a software update with the effect of simply reducing the computational workload. To make a fair performance comparison, both the output resolution and the internal resolution need to be held constant.
Additionally, 0.3.0's notes state that this mode disables the neural processing step's own temporal accumulation, leaving that job to FSR instead. This means the mechanism responsible for stabilizing images using past frames changes depending on how the processes are combined. That's a good reason to check not just how still images look, but also whether motion artifacts or fine detail flickering appear when the camera moves.
It's also worth noting that this processing-order change was already introduced in 0.3.0. So the 42% improvement announced in 0.4.0 can't be attributed to that change alone. Exactly which computations or memory operations were optimized to produce this latest major improvement isn't clear from the published release notes.
What's new in 0.4.1: improvements under heavy load
Alpha 0.4.1, released at 4:51 AM on September 27 (Japan time), reports an 8% performance improvement over 0.4.0. The developer also states that a new priority queue mode delivers an additional 9% improvement specifically when gameplay load is high.
These two figures come with different conditions attached. The 8% figure represents improvement over the previous version generally, while the 9% figure is described as an additional effect that applies specifically under heavy load. That means you can't simply add them together and conclude the tool is 17% faster across the board. Since the specific implementation and testing conditions for the priority queue aren't documented, it's best not to lump this figure together with the other improvement percentages into one universal multiplier.
For an execution system embedded within a game, performance and stability depend not just on raw computation but also on how processing is scheduled and queued. 0.3.1 similarly described changing how the tool waits on operations, both improving performance and reducing the risk of processing stalls. That same version also fixed a bug where Frame Generation displayed stale images during menus or low-motion scenes, along with a memory leak.
Looking across this series of updates, the optimization work spans everything from raw AI computation speed to how the tool cooperates with the game engine. Even if average FPS improves, the feel of gameplay won't fully improve if there are momentary stalls during demanding scenes. When evaluating 0.4.1, per-frame timing consistency is just as useful a metric as the average FPS figure.
Image quality adjustments covering color and motion
Version 0.3.3 also expanded the tools available for tuning image quality alongside speed. Beyond a GUI installer with settings editing capability, players can now choose between Default, Natural, and Cinematic style presets in-game. Two tone curves—Reinhard and ACES—are available, along with adjustable black levels and exposure.
Tone curves affect how brightness and color are rendered. Blanco notes that Reinhard generally produces better colors, but recommends ACES for games like Cyberpunk where saturation can otherwise become too intense. In other words, the preset name alone doesn't determine image quality uniformly—compatibility with a given game's native color grading matters too.
Comparing this to official DLSS 5 also raises the question of who's responsible for this kind of tuning. In NVIDIA's official implementation, the game developer selects the model and decides how and where it's applied, as well as how strong the effect is—adjusting Tone Intensity (affecting lighting and color) and Structure Intensity (affecting fine detail), while players are typically just given a simple on/off toggle.
By contrast, this unofficial tool is added to existing games by users themselves, who adjust the look via an overlay. Whether the neural processing runs correctly and whether it's been tuned scene-by-scene to match the creators' intent are two separate things that need to be evaluated independently. Checking colors and character detail in a given scene, and confirming things look right in motion too, is what turns a performance improvement into something practically usable.
Which Radeon GPUs can try it, and remaining requirements
According to the README, the target is FSR-compatible DirectX 12 games running on Windows 11. The primary supported GPUs are Radeon RX 9000 series cards, with testing reportedly done on the RX 9070 XT. The RX 7000 series is also listed as a target, but the requirements section phrases this as "should work" while soliciting reports—meaning it hasn't necessarily been verified to the same degree across all models. Older GPUs aren't currently supported at all.
Using the tool requires Adrenalin 26.1.1 or later, plus a legitimately obtained copy of the DLSS 5 DLL, "nvngx_dlssnr.dll," build 310.8.0.0. The developer states that no NVIDIA code or data is bundled with the tool—users must supply the required DLL themselves. This isn't officially supported by either NVIDIA or AMD.
There are also API limitations. Vulkan support is planned for the future and shouldn't be confused with the current DirectX 12 functionality. The developer also notes that the DLL gets blocked by games that include anti-cheat software. Simply owning a Radeon GPU doesn't guarantee the tool can be installed the same way in every game.
For those already running DLSS-NR on AMD, this string of updates is a good reason to re-test under the same settings. But drawing conclusions about the speed gap with the official implementation on GeForce hardware requires comparing the same game and rendering conditions, matching both the resolution the neural processing operates on and whether Frame Generation is enabled. Only once frame timing and in-motion image quality prove stable can the value of taking on this extra rendering workload on Radeon be judged by actual playability—rather than by the size of the reported improvement percentages.