DLSS 5 sur AMD fonctionne désormais sur trois générations de Radeon, mais l’écart matériel demeure

Daniel Blanco a étendu DLSS 5 sur AMD, passé d’un effet expérimental unique à une suite graphique en quatre parties couvrant trois générations de Radeon. La version Alpha 0.8.0, publiée le 17 octobre, ajoute DLSS Frame Generation à une collection qui comprend déjà Super Resolution, Ray Reconstruction et Neural Rendering.

Il s’agit d’un revirement important pour des fonctionnalités commercialisées autour du matériel RTX de Nvidia. Le projet DLSS-NR-on-AMD de Blanco cible désormais les cartes Radeon RX 9000, RX 7000 et RX 6000, bien que la prise en charge varie selon l’architecture. Il transforme aussi les technologies distinctes de Nvidia en modules sélectionnables au sein d’un unique gestionnaire.

Cette prouesse technique n’efface pas la fracture matérielle. Le projet reste non officiel, plusieurs résultats proviennent de tests réalisés par le développeur, et les premiers essais indépendants ont révélé des plantages ou de lourdes pertes de performances. Nvidia conserve le contrôle des modèles d’origine, du matériel pris en charge et des intégrations dans les jeux.

Ce qui a changé, c’est l’accès. Les propriétaires de Radeon peuvent désormais expérimenter presque tous les principaux composants de DLSS via un même framework, même lorsque les alternatives officielles d’AMD disposent d’une prise en charge matérielle ou logicielle plus restreinte. Le débat ne porte plus sur la possibilité de faire fonctionner ces fonctionnalités sur Radeon, mais sur leur capacité à fonctionner assez bien pour avoir de l’importance.

DLSS 5 sur AMD devient une suite graphique complète

L’Alpha 0.8.0 fait passer DLSS-NR-on-AMD d’une expérimentation de Neural Rendering à un package modulaire couvrant les principales fonctionnalités DLSS de Nvidia.

Blanco a publié le projet pour la première fois le 3 septembre, le jour même où Nvidia a rendu DLSS 5 disponible dans NBA 2K27. Son objectif initial était plus limité : exécuter le nouveau modèle Neural Rendering de Nvidia sur du matériel AMD via un environnement d’exécution de réseau neuronal spécifique aux Radeon.

Neural Rendering est le composant inhabituel. Nvidia le décrit comme une étape finale de rendu qui utilise un modèle génératif pour améliorer l’éclairage, la peau, les matériaux, les reflets et d’autres détails visuels. À la différence d’un upscaling ordinaire, il modifie l’apparence finale au lieu de seulement reconstruire une image à plus haute résolution.

La mise à jour d’octobre de Blanco ajoute les technologies environnantes nécessaires à la construction d’un pipeline DLSS plus large. Selon les notes de version 0.8.0 du projet, le package inclut désormais DLSS Super Resolution 4.5, DLSS Ray Reconstruction, DLSS Frame Generation et Neural Rendering.

Super Resolution reconstruit une image de plus haute résolution à partir d’une entrée de plus faible résolution. Ray Reconstruction remplace plusieurs débruiteurs réglés manuellement par un modèle entraîné qui reconstruit les détails issus du ray tracing. Frame Generation crée des images supplémentaires entre celles rendues de manière conventionnelle.

La version 0.8.0 prend en charge jusqu’à 4X Multi Frame Generation lorsqu’un jeu fournit les entrées DLSS Frame Generation requises. Cette désignation signifie que le pipeline peut afficher jusqu’à quatre images pour chaque image rendue de manière conventionnelle, y compris les images générées.

La mise à jour accepte également les fichiers Neural Rendering 310.9.16 de Nvidia et intègre l’upscaling FSR 4.1.1. L’intégration d’une version de FSR fournit au mod une base cohérente au lieu de dépendre de l’implémentation particulière fournie avec chaque jeu ou pilote.

Blanco regroupe ces fonctionnalités dans ce qu’il appelle un Neural Rendering Supermod. Les utilisateurs peuvent choisir des modules via une superposition plutôt que d’installer une solution distincte pour chaque fonctionnalité. Le gestionnaire NeuralHub du projet analyse les jeux, installe le loader, centralise les gros fichiers de modèles et maintient à jour les composants installés.

Le gestionnaire compte, car le processus d’installation antérieur exigeait davantage de manipulation manuelle des fichiers. Les utilisateurs devaient placer des bibliothèques dans les répertoires de chaque jeu et résoudre les problèmes titre par titre. NeuralHub réduit cette friction, sans pour autant transformer le projet en fonctionnalité de pilote prise en charge.

Un jeu compatible doit utiliser DirectX 12 et exposer des entrées FSR, DLSS ou Intel XeSS. Après avoir installé le loader, le joueur active l’une de ces technologies dans le jeu. Le mod intercepte alors ce pipeline et achemine les entrées disponibles vers les modules de sortie sélectionnés.

Les utilisateurs doivent fournir leurs propres fichiers DLL Nvidia pour les fonctions DLSS concernées. FSR est intégré au gestionnaire, mais pas les bibliothèques Nvidia. Cette exigence maintient le projet dépendant des fichiers distribués avec les jeux prenant en charge ces technologies.

La prise en charge des architectures doit également être nuancée. Le projet affirme que chaque fonctionnalité DLSS principale fonctionne sur RDNA 4 et RDNA 3, qui équipent les cartes Radeon RX 9000 et RX 7000. La prise en charge de RDNA 2 reste en cours de test, Neural Rendering étant disponible avant que plusieurs autres modules n’atteignent cette génération.

Cela rend l’expression « trois générations » exacte à l’échelle du projet, mais elle ne signifie pas une parité fonctionnelle complète sur chaque carte prise en charge. Les propriétaires de Radeon RX 6000 devraient considérer la compatibilité actuelle comme partielle et évolutive.

La version ajoute un mode DirectX 12 natif destiné à réduire les ralentissements associés à l’interopérabilité entre les systèmes graphiques et de calcul. Elle apporte également l’exécution DirectX 12 à plusieurs fonctionnalités sur RDNA 3, ainsi qu’un chargement plus rapide et des optimisations réseau générales.

Il ne s’agit pas de simples ajouts de menus. Blanco indique que l’environnement d’exécution est une réimplémentation complète du chemin d’exécution des réseaux neuronaux pour les architectures AMD, incluant les kernels HIP, les agencements mémoire et l’intégration aux jeux. Le projet affirme qu’il ne traduit pas le code Nvidia pendant l’exécution.

Cette distinction explique pourquoi la mise à jour représente davantage qu’un simple basculement de marque. Le système doit prendre des modèles conçus autour de la pile Nvidia et exécuter leurs charges de travail via du code compatible Radeon tout en préservant les entrées attendues par chaque jeu.

Le nouveau package crée donc la tension centrale de l’article. Le logiciel a rendu la suite Nvidia suffisamment portable pour fonctionner ailleurs, mais une exécution réussie n’équivaut pas à une efficacité native, une fiabilité ou une prise en charge officielle.

L’accès sur Radeon met sous pression la stratégie fonctionnelle d’AMD

Le mod met AMD sous pression, car il révèle une demande de compatibilité plus large alors même que Radeon dispose déjà d’alternatives à la plupart des fonctions DLSS.

AMD ne part pas d’une pile graphique vide. Sa famille FSR couvre l’upscaling et la génération d’images, tandis que FSR « Redstone » ajoute Ray Regeneration et Radiance Caching fondés sur le machine learning. Radeon Anti-Lag 2 traite la latence dans les jeux pris en charge.

L’écart réside dans une disponibilité inégale. AMD indique que son actuelle suite de fonctionnalités FSR dépend des jeux pris en charge, des générations de Radeon et d’exigences d’intégration spécifiques. Toutes les fonctionnalités FSR ne parviennent pas à chaque propriétaire de Radeon par le même chemin.

La collection complète de FSR Redstone cible le matériel Radeon RX 9000. AMD liste l’upscaling fondé sur le machine learning pour les cartes RX 7000 et RX 9000, avec une prise en charge des RX 6000 prévue pour 2027. Les anciennes versions de FSR couvrent davantage de matériel, mais n’offrent pas les mêmes modèles entraînés.

Le projet de Blanco s’attaque à cette fragmentation sous un autre angle. Il utilise les points d’intégration existants de FSR, DLSS ou XeSS comme portes d’entrée, puis laisse les joueurs choisir parmi plusieurs modules Nvidia et AMD reconstruits.

Cela ne signifie pas que le mod prend en charge tous les jeux DirectX 12. Un titre doit toujours disposer d’une interface d’upscaling adaptée et des entrées requises pour la fonctionnalité choisie. Ray Reconstruction requiert des données de ray tracing, tandis que DLSS Frame Generation nécessite un chemin Frame Generation compatible et exige actuellement une usurpation de GPU.

L’approche élargit néanmoins l’espace de recherche pratique. Plutôt que d’attendre qu’un développeur ajoute une fonctionnalité précise d’un fournisseur, les moddeurs peuvent tenter de réutiliser des informations déjà disponibles dans le pipeline de rendu d’un jeu.

Cela compte parce que les joueurs PC considèrent de plus en plus la reconstruction d’image et les images générées comme faisant partie de la valeur d’une carte graphique. Les performances brutes de rastérisation ne racontent plus toute l’histoire lorsque le ray tracing exigeant peut dépendre de l’upscaling, du débruitage et de la synthèse d’images.

Nvidia a renforcé cette association en regroupant ses technologies sous DLSS. Un jeu prenant en charge DLSS peut exposer Super Resolution, Ray Reconstruction et Frame Generation via des interfaces liées, bien que l’éligibilité matérielle varie selon la fonctionnalité.

AMD dispose d’outils comparables, mais l’histoire de leur implémentation est moins uniforme. FSR s’étend sur plusieurs générations et méthodes techniques, de l’upscaling spatial à la reconstruction temporelle et aux modèles de machine learning. Ces différences protègent une large compatibilité, mais elles compliquent aussi les attentes en matière de fonctionnalités.

Le mod met donc AMD sous pression sur la portée logicielle plutôt que sur le simple nombre de fonctionnalités. Radeon dispose déjà d’une réponse officielle pour l’upscaling, les images générées et les détails reconstruits par ray tracing. Il n’offre pas encore d’équivalent direct à l’étape de rendu final génératif de DLSS 5.

Les recherches de Nvidia sur Neural Rendering décrivent un modèle de diffusion en une étape, dans l’espace des pixels, conditionné par l’image actuelle, les vecteurs de mouvement, l’état temporel et les contrôles du développeur. L’entreprise affirme qu’il préserve la structure voulue tout en ajoutant des détails d’apparence appris.

Il s’agit d’un objectif différent de la reconstruction de résolution manquante. DLSS 5 peut synthétiser des propriétés visuelles que le moteur de rendu conventionnel n’a pas calculées intégralement. Nvidia le présente comme un complément au rendu fondé sur la physique, plutôt que comme un substitut aux ressources de jeu ou à la direction artistique.

Blanco a initialement ciblé cette capacité absente, car aucune fonctionnalité Radeon directe ne pouvait l’activer. La suite complète est arrivée plus tard, transformant une solution à une fonction manquante en une couche de compatibilité plus large.

Cela crée une comparaison inconfortable pour AMD. Un développeur indépendant montre que le matériel Radeon peut exécuter des charges de travail associées à la pile graphique de Nvidia, même si les résultats restent plus lents et moins fiables.

L’implication n’est pas qu’AMD devrait adopter la technologie de Nvidia. Elle est que les utilisateurs de Radeon accordent de la valeur à un accès flexible dans davantage de jeux et sur davantage de générations matérielles. La popularité des loaders non officiels reflète une demande que les listes de compatibilité officielles ne satisfont pas toujours.

Le projet comptait environ 2 800 étoiles GitHub lors de son examen le 20 octobre. Ce chiffre ne prouve pas une utilisation quotidienne généralisée, mais il signale une attention significative pour un utilitaire alpha nécessitant des bibliothèques manuelles et des modifications de jeux non prises en charge.

Pour AMD, la réponse imposée est de long terme. L’entreprise doit étendre la prise en charge de Redstone, améliorer la disponibilité intergénérationnelle et encourager les développeurs à exposer des entrées cohérentes. Dans le cas contraire, les projets communautaires continueront de définir ce que l’ancien matériel Radeon peut tenter de faire.

Le portage logiciel ne supprime pas l’avantage matériel de Nvidia

DLSS 5 sur AMD inverse la restriction d’accès, mais il n’inverse pas le contrôle de Nvidia sur les modèles ni son avantage en matière de matériel optimisé pour les charges de travail neuronales.

DLSS 5 cible officiellement les GPU GeForce RTX série 50. Les indications de Nvidia sur DLSS 5 publiées en septembre indiquent que la technologie fonctionne aux côtés de Super Resolution, Frame Generation, Ray Reconstruction, du ray tracing et du path tracing.

Le matériel RTX intègre des Tensor Cores dédiés aux opérations matricielles utilisées par les réseaux neuronaux. Les architectures Radeon peuvent également exécuter des calculs matriciels, mais leur allocation de ressources et les formats pris en charge diffèrent. Une implémentation logicielle doit fonctionner dans ces contraintes architecturales.

Le runtime de Blanco fait précisément cela en reconstruisant le chemin d’exécution pour les GPU AMD. Il mappe les réseaux neuronaux sur des noyaux HIP et des dispositions mémoire adaptées aux Radeon, au lieu de s’appuyer sur un runtime Nvidia natif.

C’est le mécanisme à l’origine de cette réussite comme de ses limites. La portabilité provient de la réimplémentation de l’exécution, non du fait que les cartes Radeon disposent d’un matériel identique. Plus une charge de travail se rapproche d’une inférence neuronale soutenue, plus ces différences architecturales peuvent affecter la vitesse.

Les performances du projet se sont rapidement améliorées. Les notes de la version 0.8.0 revendiquent une amélioration de 25 % du Neural Rendering sur RDNA 3. Elles revendiquent également un gain de 6 à 16 % sous de fortes charges de jeu DirectX 12, grâce à des changements d’accumulation temporelle introduits avec la version 0.7.0.

Ces chiffres décrivent des évolutions signalées par les développeurs entre différentes versions. Il ne s’agit pas de comparaisons normalisées avec une exécution Nvidia native. Les paramètres de jeu, la résolution de sortie, le choix du modèle, les pilotes et les entrées de rendu peuvent tous modifier le résultat.

Blanco affirme qu’une RX 9070 XT peut atteindre 90 à 100 images par seconde en 1080p avec le modèle HT Neural Rendering complet. Il affirme aussi que le rendu est similaire au DLSS natif, bien que certains effets ne fonctionnent pas entièrement.

L’objectif de développement annoncé est d’atteindre les performances d’une GeForce RTX 5070 Ti. Cela reste une ambition, et non un résultat vérifié. Aucune vaste suite de benchmarks indépendants n’établit encore la parité selon les jeux ou les conditions de qualité d’image.

Des tests antérieurs illustrent à la fois la rapidité des progrès et la difficulté persistante des comparaisons. Des essais de septembre cités par la couverture de DLSS-NR montraient que Cyberpunk 2077 passait d’environ 30 images par seconde à près de 50 après de rapides améliorations du runtime.

La même couverture évoquait un gain revendiqué de 74 % entre deux builds alpha successifs. Ce progrès était important pour le développement, mais il partait d’une base faible. Le jeu restait nettement plus rapide sans Neural Rendering activé.

Cet historique suggère une marge d’optimisation au sein du runtime. Il ne démontre pas que le logiciel seul puisse combler l’écart restant. L’exécution sur Radeon pourrait finir par atteindre un plafond imposé par le débit matriciel disponible, les transferts mémoire ou les ressources de calcul partagées.

La Frame Generation complique également les affirmations de performances. Les images générées augmentent la fréquence d’images affichée sans augmenter la cadence des nouvelles mises à jour de l’état du jeu. Un compteur plus élevé peut améliorer la fluidité visuelle, tandis que la réactivité des commandes reste liée au rythme de rendu sous-jacent.

La Multi Frame Generation rend cette distinction plus importante. Si le système crée plusieurs images autour de chaque image rendue de façon traditionnelle, les artefacts et le comportement de la latence dépendent fortement de la qualité et du timing du flux de base.

La Ray Reconstruction repose sur une dépendance différente. Elle nécessite des vecteurs de mouvement, la profondeur, des informations de surface et des entrées issues du ray tracing fournies par le jeu. Un chemin d’entrée incomplet ou incompatible peut réduire la qualité, même lorsque le modèle neuronal lui-même s’exécute correctement.

La conception modulaire du projet permet aux utilisateurs de combiner les entrées et sorties de manière inhabituelle. Par exemple, les entrées XeSS d’un jeu peuvent alimenter Neural Rendering tandis que FSR gère l’upscaling. Cette flexibilité est précieuse pour les expérimentations, mais chaque combinaison crée une nouvelle surface de compatibilité.

Nvidia conserve un avantage important, car l’entreprise coordonne les modèles d’origine, les pilotes, les intégrations développeur et les cibles matérielles. Elle peut optimiser le chemin complet plutôt que de s’adapter à des interfaces conçues pour un autre fournisseur.

AMD conserve un autre avantage grâce à la stratégie de déploiement large de FSR. Certaines versions de FSR fonctionnent sur les GPU de plusieurs fournisseurs, et les développeurs peuvent les intégrer sans exiger de carte Radeon. Redstone réduit cette universalité à mesure qu’AMD ajoute davantage de composants d’apprentissage automatique.

Le projet de Blanco se situe entre ces deux approches. Il traite les technologies des fournisseurs comme des modules pouvant être détachés de leur chemin matériel prévu. Son existence suggère que les interfaces sont plus réutilisables que ne le laissent entendre leurs frontières marketing.

Le portage ne rend pas ces frontières insignifiantes. Le support officiel détermine toujours quelles configurations bénéficient de tests de pilotes, d’aide aux développeurs, de mises à jour prévisibles et de service client. La compatibilité du mod peut se rompre lorsqu’un jeu, un pilote ou une bibliothèque fournisseur évolue.

Le véritable renversement est donc spécifique. Nvidia ne détient plus une exclusivité technique absolue quant aux endroits où ses sorties DLSS visibles peuvent apparaître. L’entreprise conserve toutefois l’argument le plus solide en matière de performances maîtrisées et de support.

Les performances, la stabilité et l’anti-cheat relativisent cette victoire

La plus grande incertitude ne concerne pas la possibilité de lancer les fonctions DLSS sur Radeon, mais la capacité des joueurs ordinaires à s’y fier dans de vrais jeux.

Le projet reste un logiciel alpha. Les notes de version 0.8.0 répertorient des correctifs pour une fuite de mémoire GPU et un rare échec au démarrage, tout en signalant des problèmes d’installation non résolus. Le nouveau launcher Epic Games n’est pas pris en charge, et l’ajout manuel de jeux peut échouer.

Les exigences annoncées comprennent Windows 11, un pilote Adrenalin en version 26.1.1 ou ultérieure, un jeu DirectX 12 et des bibliothèques DLSS fournies par l’utilisateur. La prise en charge de Vulkan et de Linux est prévue, mais indisponible dans la version actuelle.

L’anti-cheat constitue une frontière plus nette. Le projet avertit que les jeux équipés d’anti-cheat bloqueront sa DLL. Les utilisateurs doivent désactiver l’anti-cheat lorsqu’un jeu permet cette option, ce qui limite généralement l’expérimentation aux modes hors ligne ou autrement autorisés.

Cette restriction écarte de nombreux titres multijoueurs compétitifs du public visé en pratique. Elle reflète également une conception de sécurité raisonnable : les systèmes anti-cheat sont censés rejeter le code non reconnu injecté dans le processus d’un jeu.

L’installation s’est améliorée grâce à NeuralHub, mais une installation simplifiée ne signifie pas un comportement prêt pour le grand public. Un gestionnaire peut centraliser les fichiers et automatiser la détection, tandis que la compatibilité sous-jacente avec les jeux demeure fragile.

Des tests indépendants ont déjà démontré cette fragilité. Un test sur RX 9070 XT a rencontré un avertissement de sécurité Windows, une scène 3D noire, des plantages, une régression du pilote et des problèmes de lancement de Cyberpunk 2077 via Steam.

Ce test a finalement exécuté Neural Rendering, mais les performances sont tombées de 61 images par seconde à 9 en 4K avec le ray tracing et FSR équilibré. Le résultat représentait une baisse de 85 % dans cette configuration.

Un seul essai ne peut pas définir tous les builds ou toutes les configurations actuels. Il a précédé certaines optimisations ultérieures, et les performances de Neural Rendering varient considérablement selon la résolution, les paramètres du modèle, la complexité de la scène et le nombre de passes.

Il offre néanmoins un contrepoids nécessaire au résultat en 1080p du développeur. Une fonction atteignant 90 à 100 images par seconde dans une configuration peut encore devenir impraticable avec une charge de travail plus lourde.

Tom’s Hardware a rapporté des résultats utilisateurs tout aussi contrastés après la version 0.8.0. Certains utilisateurs ont décrit peu ou pas de perte par rapport à FSR natif, tandis que d’autres ont signalé des baisses à un chiffre ou atteignant 25 % selon les jeux.

Ces témoignages ne disposent pas des contrôles d’une suite de benchmarks formelle. Ils montrent néanmoins que « fonctionne sur Radeon » couvre un large éventail d’expériences, du déploiement utile à l’expérimentation instable.

La qualité d’image exige la même prudence. Blanco affirme que le rendu ressemble au DLSS natif, à l’exception d’effets qui ne fonctionnent pas entièrement. Cette réserve est importante, car Neural Rendering modifie les matériaux et l’éclairage au lieu de simplement accroître la netteté.

Un reflet manquant, un visage instable, une surface modifiée ou un détail temporellement incohérent peuvent être plus difficiles à quantifier qu’une fréquence d’images moyenne. Des captures d’écran côte à côte peuvent masquer des problèmes devenant visibles en mouvement.

Le mode multipass ajoute un autre compromis. La version 0.8.0 peut exécuter jusqu’à trois passes de Neural Rendering par image, avec des styles et intensités distincts. Davantage de passes peuvent accroître l’effet visuel, mais elles ajoutent aussi du travail de calcul.

Le projet dépend également de bibliothèques de modèles propriétaires fournies par les jeux pris en charge. Bien que Blanco affirme que son code ne contient aucune implémentation Nvidia, les utilisateurs ont toujours besoin de DLL Nvidia compatibles. Une future mise à jour de bibliothèque pourrait modifier le comportement ou introduire un nouveau défi de compatibilité.

Rien ne garantit non plus que les studios de jeux prendront en charge les bugs causés par le loader. Un développeur ne peut raisonnablement pas valider chaque combinaison de runtime injecté, fichier de modèle, entrée d’upscaler et pilote Radeon.

Aucune de ces réserves n’efface l’accomplissement technique. Les projets de modding alpha commencent souvent avec une compatibilité limitée, une installation manuelle et des coûts de performances élevés. Des itérations rapides peuvent résoudre des problèmes qui paraissent initialement fondamentaux.

Cependant, la charge de la preuve a désormais changé. La première version a prouvé que DLSS 5 Neural Rendering pouvait s’exécuter sur Radeon. La version 0.8.0 prouve qu’un ensemble plus large peut partager un même framework modulaire.

La prochaine preuve doit venir de résultats reproductibles. Les testeurs ont besoin de scènes, pilotes, résolutions, versions de modèles et mesures de latence identiques sur RDNA 2, RDNA 3, RDNA 4 et du matériel GeForce natif.

En attendant ces résultats, les affirmations de qualité Nvidia native ou de performances de RTX 5070 Ti doivent rester attribuées au développeur. Le projet a démontré l’accès, pas la parité.

Trois signaux détermineront si le mod transforme le jeu sur Radeon

La prochaine étape sera déterminée par des benchmarks reproductibles, une prise en charge complète de RDNA 2 et les réponses officielles d’AMD ou de Nvidia.

Le premier signal est un ensemble de benchmarks indépendants pour la version 0.8.0 ou ultérieure. Il devrait comparer les mêmes scènes de jeu sur une RX 9070 XT et une carte GeForce appropriée, tout en séparant Super Resolution, Ray Reconstruction, Frame Generation et Neural Rendering.

La fréquence d’images moyenne seule ne suffira pas. Les tests devraient inclure les performances aux faibles percentiles, la latence d’entrée, la régularité des images, l’utilisation de la mémoire vidéo, la stabilité temporelle et les artefacts visuels. Les images générées doivent être distinguées séparément des images rendues de façon traditionnelle.

Des résultats cohérents proches des affirmations du développeur en 1080p renforceraient l’idée que le runtime est passé de la démonstration à l’usage pratique. De fortes variations entre les titres suggéreraient que le travail de compatibilité reste plus important que l’optimisation brute.

Le deuxième signal est l’extension promise du projet pour les cartes Radeon RX 6000. La documentation actuelle indique que RDNA 2 peut exécuter Neural Rendering en phase de test, tandis que plusieurs autres fonctions restent absentes.

Déployer la majeure partie de la suite sur RDNA 2 montrerait que l’abstraction architecturale s’étend au-delà des conceptions Radeon les plus récentes. Cela donnerait aussi à une large base installée accès à des fonctions peu susceptibles d’arriver prochainement par la nouvelle pile officielle d’AMD.

L’échec de l’extension de ces modules affaiblirait le cadrage autour de « trois générations ». La suite complète resterait concentrée sur RDNA 3 et RDNA 4, RX 6000 servant de cible expérimentale limitée.

Le troisième signal sera une réponse des fournisseurs de GPU. AMD pourrait accélérer la disponibilité de Redstone, élargir la prise en charge du matériel plus ancien ou améliorer les chemins de mise à niveau au niveau des pilotes pour les jeux dotés d’intégrations FSR compatibles.

Nvidia pourrait laisser le projet tranquille, modifier le comportement de ses bibliothèques ou préciser comment ses fichiers de modèles peuvent être utilisés hors des configurations GeForce prises en charge. Même une mise à jour technique qui casserait involontairement le mod révélerait à quel point le projet reste dépendant du cycle de publication de Nvidia.

Les développeurs de jeux font également partie de ce signal. Des entrées plus standardisées pour le mouvement, la profondeur, l’exposition et le ray tracing faciliteraient l’échange des technologies de reconstruction. Des systèmes de validation ou anti-tamper plus stricts iraient dans la direction opposée.

Le scénario le plus probable à court terme n’est ni une parité totale ni un échec immédiat. DLSS-NR-sur-AMD peut devenir un outil utile pour les passionnés tout en restant inadapté aux acheteurs qui attendent une fiabilité en un clic.

Cela resterait important. Les moddeurs ont à maintes reprises prolongé la durée d’utilité des fonctions graphiques en créant des wrappers, en remplaçant des bibliothèques et en exposant des options que les fournisseurs limitent selon les générations de produits.

La version 0.8.0 va plus loin en plaçant quatre technologies phares derrière un seul gestionnaire orienté Radeon. Elle montre que certaines parties des piles graphiques modernes peuvent être dissociées du parcours prévu par leur fournisseur, même lorsque l’expérience finale dépend toujours du matériel.

Pour les propriétaires de Radeon, la question pratique est simple : échangeriez-vous le support officiel et une compatibilité prévisible contre l’accès à des fonctionnalités de rendu que votre carte n’a jamais été conçue pour exécuter ? Surveillez les prochaines publications de benchmarks, la liste des fonctionnalités RDNA 2 et les mises à jour des fournisseurs avant de considérer DLSS 5 sur AMD comme autre chose qu’une expérience convaincante.