Choosing a graphics card increasingly means choosing a software ecosystem. Nvidia provides DLSS technologies for image reconstruction, ray-tracing improvements and generated frames. AMD offers its own FidelityFX Super Resolution family. The underlying objectives are similar, but the implementations differ in important ways. Some capabilities rely on proprietary neural networks, dedicated hardware features and close integration with game engines. That can leave players unable to use a particular technology even when their graphics card has considerable computing power. Independent developer Daniel Blanco has been exploring that limitation through DLSS-NR-on-AMD. The project began by bringing Nvidia's neural-rendering technology to Radeon graphics cards. Its latest alpha release goes considerably further. Version 0.8.0 brings support for four major DLSS technologies to RDNA 3 and RDNA 4 hardware, according to the project's documentation. Tom's Hardware covered the development on October 18. The result is an interesting technical achievement, although it should not be confused with official AMD or Nvidia support.

The mod now covers four major DLSS technologies

The expanded project includes DLSS Super Resolution, Ray Reconstruction, Frame Generation and DLSS 5 Neural Rendering. Each addresses a different part of the graphics pipeline. Super Resolution reconstructs a higher-resolution image from a lower-resolution internal render. Its purpose is to reduce the amount of rendering work required while maintaining useful visual detail. Ray Reconstruction applies neural-network processing to information generated through ray tracing. Frame Generation produces additional displayed frames between those calculated by the game engine. DLSS 5 Neural Rendering takes AI-assisted image processing further by modifying or enriching aspects of the final presentation. Combining these capabilities in one project is significant. But it does not mean every game can enable every feature. Different functions depend on different inputs from the rendering engine. A game may expose the information necessary for one module while lacking the data needed by another. The mod provides a way to experiment with those technologies outside their original hardware ecosystem. It does not remove every dependency built into their operation.

This is more than a simple compatibility trick

The developer describes the project as a reimplementation of the neural-network execution environments required to run DLSS models on AMD hardware. That is more involved than changing a device identifier. The implementation includes AMD-oriented HIP compute kernels, memory-management adaptations and game-integration components. HIP provides programming tools for workloads that can execute on AMD graphics hardware. The goal is to perform the mathematical operations required by the models using resources available on Radeon GPUs. Nvidia's architecture and software environment are different. A model designed around one implementation cannot necessarily be executed efficiently on another without significant work. Blanco says his runtime has been rewritten for AMD rather than simply translating Nvidia instructions during execution. This distinction explains both the project's ambition and its limitations. Being able to execute a neural model demonstrates technical feasibility. Achieving the same throughput, latency and memory efficiency as the original hardware requires further optimization. The model's existence and the hardware's ability to perform mathematical operations are only part of the problem.

RDNA 3 and RDNA 4 get the broadest support

The alpha 0.8.0 documentation identifies Radeon RX 7000 and RX 9000 GPUs as the main targets. These cards use AMD's RDNA 3 and RDNA 4 architectures. The developer says all four major DLSS modules are now supported across those families. The Radeon RX 6000 series has a more limited status. Its RDNA 2 architecture remains experimental within the project. Neural Rendering is reported to work in certain configurations, while additional modules are planned for future releases. That distinction matters. Listing a GPU family as supported does not establish that every card in the family has been comprehensively tested. Different models provide different amounts of computing power and memory. The cost of running an additional neural workload can also affect ordinary rendering performance. A high-end Radeon RX 9070 XT may produce usable results in circumstances where a smaller GPU struggles. Users should not interpret broad architecture support as a universal compatibility guarantee.

NeuralHub makes the project easier to manage

The developer has introduced NeuralHub to organize the various components. The manager allows users to import the required libraries, identify supported games and configure the available rendering functions. That makes the expanded project more manageable than maintaining separate manual modifications. However, installation remains more complex than enabling a native graphics setting. The documented requirements include Windows 11, a compatible DirectX 12 game and AMD Adrenalin driver version 26.1.1 or newer. The game must provide an integration that can work with the required FSR, DLSS or XeSS features. Users must also supply the Nvidia libraries associated with the modules they want to run. Neural Rendering requires a suitable version of nvngx_dlssnr.dll. Other DLSS features use additional libraries. The project explicitly requires users to obtain these components legitimately. It does not simply redistribute Nvidia's proprietary software as a new Radeon driver package. The installation process remains an important limitation for anyone unfamiliar with game modding.

Frame Generation comes with additional requirements

Frame Generation is one of the most interesting additions. It is also one of the more complicated technologies to reproduce. Generating a convincing intermediate frame requires information about movement, scene changes and sometimes interface elements. The game engine must provide the appropriate inputs. Without those inputs, the generated image can contain visible errors or behave incorrectly during rapid motion. The project's documentation says DLSS Frame Generation may require additional hardware-recognition handling and compatible game-provided data. Not every DirectX 12 game will necessarily work. There is also a distinction between displayed frame rate and actual responsiveness. Frame Generation can increase the number of images shown without making the game's underlying simulation run at the same frequency. That means a higher FPS counter does not automatically represent a proportional reduction in input latency. For visually demanding single-player games, the compromise may be worthwhile. For competitive games that demand precise controls, the relationship between frame rate, latency and image quality needs greater scrutiny. The mod's ability to enable generated frames should therefore be evaluated through more than one performance metric.

Can a Radeon match native Nvidia performance?

The developer reports increasingly usable performance. Current project documentation mentions approximately 90 to 100 frames per second at 1080p on a Radeon RX 9070 XT using the complete Neural Rendering model under the described conditions. Blanco has also expressed an ambition to approach the performance of a GeForce RTX 5070 Ti. That remains an objective, not a general result established through independent testing. Performance varies according to the graphics card, game, scene and selected model. The neural workload may consume memory and processing resources that would otherwise be available to the game's rendering pipeline. Even when image quality improves, the computational cost can be substantial. Community reports describe different outcomes depending on the exact configuration. Some users report relatively small penalties. Others encounter significantly larger losses. Those observations should not be combined into one universal performance claim. A proper comparison needs to consider rendered frames, generated frames, latency, image quality and visual artifacts. Matching one headline frame-rate result is not the same as delivering identical overall behavior.

Nvidia's own DLSS 5 is evolving rapidly

The community release arrives as Nvidia continues optimizing its neural-rendering technology. An October model update reduces the model's footprint by approximately 24 percent, bringing it to around 118 million parameters. Nvidia also reports about 20 percent lower VRAM use at 4K. Those changes are intended to reduce the computational cost of Neural Rendering on supported hardware. They matter to projects such as DLSS-NR-on-AMD for two reasons. A more efficient model may become easier to run on different GPU architectures. At the same time, changes to Nvidia's software can require further work from community developers. The target is constantly moving. A successful implementation today may need adaptations when new models, libraries or game integrations become available. That makes long-term compatibility more difficult than demonstrating that one build works in one game. The port must keep evolving alongside the underlying technology.

Anti-cheat software can prevent the mod from working

One important limitation involves games protected by anti-cheat systems. The mod works by integrating additional software components with the game process. Some anti-cheat tools can block those libraries. The developer acknowledges that limitation in the project documentation. Players should not attempt to bypass anti-cheat protections to make the software work. Experiments are more appropriate in compatible single-player environments where modifications are allowed. There are also ordinary software-security considerations. The mod relies on components that interact closely with the game's execution environment. Obtaining DLL files from unknown websites introduces unnecessary malware risk. The project requires legitimately obtained Nvidia libraries and carries no official warranty. Users should treat it as experimental software rather than a supported driver feature. It may stop working following a game update or graphics-driver change. That is part of the risk associated with relying on a community implementation of proprietary rendering technologies.

This is not an official AMD feature

DLSS-NR-on-AMD is an independent project. It is not a new release of Radeon Software Adrenalin. It is not an AMD implementation of FidelityFX Super Resolution. And it is not officially supported by Nvidia. The project's repository explicitly states that it is not affiliated with either company. According to the developer, the distributed implementation contains independently written runtime code rather than Nvidia's proprietary code. Users still need to provide the required Nvidia libraries separately. Those conditions do not make DLSS technology open source. Nor do they establish a right to unrestricted distribution of every component involved. For Radeon owners, the project is best understood as an experiment that may make previously unavailable visual features accessible. Official FSR technologies remain separate alternatives with their own integration and support arrangements. The two approaches can coexist without one automatically replacing the other.

The bigger story is about proprietary rendering ecosystems

The project raises an interesting question about modern graphics technology. How much of a feature's exclusivity is determined by the hardware, and how much comes from the software environment surrounding it? There is rarely a simple answer. Nvidia invests in neural models, dedicated hardware and specialized software integration. AMD uses a different architecture and develops competing reconstruction technologies. Some mathematical operations can be implemented across both platforms. But the efficiency and reliability of those implementations depend heavily on their execution environment. DLSS-NR-on-AMD operates in that difficult space. It shows that independent developers can sometimes reproduce essential runtime functionality for another architecture. It also demonstrates why doing so requires substantial technical work. Memory management, GPU scheduling, rendering inputs and model execution all need careful handling. Interoperability is not simply a matter of changing a setting. The achievement is meaningful precisely because the engineering is difficult.

An impressive alpha, not a replacement for native support

Version 0.8.0 represents a significant step forward for DLSS-NR-on-AMD. The developer now claims broad support for the four major DLSS modules across RDNA 3 and RDNA 4 hardware. RDNA 2 is beginning to receive experimental support, while NeuralHub provides a more convenient way to manage the expanding feature set. The results show how far a community-driven graphics project can progress. But important limitations remain. Game compatibility varies. Performance depends on the workload and GPU. Certain functions require additional game-engine inputs. Anti-cheat systems can block the modification, and users must obtain the necessary libraries legitimately. There is no official support from AMD or Nvidia. For enthusiasts interested in GPU architecture and modding, the project is genuinely exciting. For players who simply want to install a game and enjoy predictable performance, native supported technologies remain the more reliable choice. DLSS-NR-on-AMD does not turn a Radeon into a GeForce. It demonstrates that some of the software boundaries between them can be crossed through independent engineering. That is already an important result, even if the road from a promising alpha to dependable everyday software remains long.