La démo navigateur de Nvidia DLSS 5 s’affranchit des RTX, mais nécessite plusieurs secondes de rendu

La démo navigateur de DLSS 5 de Nvidia aurait transféré un modèle neuronal de 147 Mo vers WebGPU, malgré la dépendance officielle de cette fonctionnalité au matériel RTX et aux intégrations natives dans les jeux. Le développeur MAAN affirme que l’expérience fonctionne également sur macOS et sur des GPU non-Nvidia. La contrepartie est considérable : lors d’un test indépendant, chaque image traitée a nécessité une ou deux secondes.

Cet écart définit mieux le projet que sa promesse de compatibilité. MAAN n’a pas fait de DLSS 5 une fonctionnalité pratique pour le jeu dans un navigateur. Le développeur semble avoir séparé le modèle de rendu neuronal de Nvidia de la chaîne habituelle de pilotes, de SDK et de matériel de l’entreprise.

L’expérience met donc sous pression le modèle de déploiement contrôlé de Nvidia, et non son avance en matière de performances de jeu. Nvidia a introduit DLSS 5 dans NBA 2K27 pour les systèmes RTX série 50 et GeForce NOW. L’implémentation de MAAN exposerait une partie du même processus visuel au moyen d’une API graphique de navigateur ordinaire.

Le résultat constitue un test de portabilité intrigant, avec de nombreuses questions non résolues. Ses poids proviendraient d’une bibliothèque divulguée, son code source n’était pas disponible lorsque les premiers articles sont parus, et sa sortie reste trop lente pour le jeu. L’enjeu est désormais de savoir si une inspection indépendante valide l’implémentation et identifie des usages où plusieurs secondes par image restent acceptables.

La démo navigateur de Nvidia DLSS 5 déplace le rendu neuronal hors du circuit officiel de Nvidia

Le changement important n’est pas que DLSS 5 fasse soudainement tourner des jeux dans un navigateur. C’est qu’un modèle de rendu entraîné par Nvidia s’exécuterait sans passer par le chemin d’intégration DLSS documenté par Nvidia.

MAAN a publié la démonstration le 16 septembre 2026. Selon le premier article sur la démo navigateur, la page fonctionne via Cloudflare Workers et s’ouvre sur une scène intitulée « Cowboy Gramps ». Elle comprend des contrôles ajustables, des vues de comparaison et la prise en charge de modèles 3D fournis par les utilisateurs.

Le développeur décrit le projet comme une réimplémentation du réseau neuronal DLSS 5 au moyen de shaders de calcul WebGPU. WebGPU est une API de navigateur qui envoie des tâches graphiques modernes et de calcul généraliste au GPU de l’appareil. Un shader de calcul est un programme GPU conçu pour effectuer des calculs parallèles plutôt que pour dessiner directement un triangle ou un pixel.

Cette distinction est importante. La page ne semble pas appeler le runtime DLSS habituel de Nvidia via un pont navigateur caché. Elle exprimerait plutôt les opérations du modèle neuronal sous forme de charges de travail GPU compatibles avec le navigateur.

MAAN indique que les poids neuronaux occupent environ 147 Mo. Le runtime JavaScript compressé ajoute environ 1 Mo. Les poids contiennent les paramètres appris utilisés par le réseau neuronal, tandis que le runtime organise les calculs nécessaires à leur application.

Ces chiffres rendent le projet volumineux pour une page web, mais suffisamment léger pour une expérience interactive hébergée. Après le téléchargement initial, le navigateur peut envoyer le travail au GPU local via WebGPU. Cloudflare héberge l’application, mais les informations disponibles indiquent que l’appareil effectue le traitement neuronal.

La démo accepterait des formats courants de modèles 3D par sélection de fichier ou glisser-déposer. Cette fonction transforme la page en davantage qu’une vidéo fixe ou une collection de captures d’écran préparées. Les utilisateurs peuvent tester la manière dont le modèle traite leurs propres ressources, même si le comportement du projet en matière de sécurité et de confidentialité exige encore une inspection du code source.

L’interface sépare également le déplacement ordinaire du modèle du traitement neuronal. Lors d’un test sur un ordinateur de bureau RTX série 40, la rotation de la visionneuse 3D est restée fluide. L’application du traitement DLSS 5 à une image a nécessité une ou deux secondes, en particulier dans le mode en direct.

Ce délai est au cœur de toute description exacte. Un rendu de deux secondes équivaut à une demi-image traitée par seconde. Les jeux en temps réel visent normalement plusieurs dizaines d’images par seconde, chaque image ne disposant que de quelques millisecondes de traitement.

La démo n’est donc pas un portage navigateur de l’expérience NBA 2K27 complète. Elle se comprend mieux comme un test d’exécution portable du composant neuronal. Le moteur de jeu environnant, les données de mouvement, les contrôles de latence et le pipeline de génération d’images constituent des problèmes distincts.

MAAN affirme également que la page fonctionne sur macOS. Cette affirmation est plausible au niveau de l’API, car les implémentations WebGPU peuvent traduire les charges de travail du navigateur vers le système graphique Metal d’Apple. Elle n’établit pas une vitesse, une qualité visuelle ou un comportement numérique identiques sur tous les Mac et dans tous les navigateurs.

La même prudence s’applique aux GPU non-Nvidia. WebGPU est conçu pour couvrir plusieurs fabricants de matériel, mais chaque appareil présente des limites et des caractéristiques de performances différentes. Exécuter une charge de travail n’est pas la même chose que l’exécuter efficacement.

L’événement de base crée néanmoins une tension réelle. Nvidia présente DLSS 5 comme une fonctionnalité de jeu RTX étroitement intégrée. L’implémentation rapportée de MAAN traite son réseau neuronal comme un graphe de calcul portable, susceptible d’être reconstruit sur une couche graphique web standard.

Pourquoi WebGPU modifie la frontière matérielle

WebGPU remplace le chemin d’exécution propriétaire de Nvidia par une couche de navigateur commune, troquant l’optimisation spécialisée contre la portabilité.

Nvidia propose habituellement aux développeurs de jeux deux voies établies pour intégrer DLSS. Ils peuvent utiliser l’intégration NGX de l’entreprise ou adopter Streamline, un framework qui s’intercale entre un jeu et son API de rendu.

Nvidia décrit l’intégration Streamline comme une couche basée sur des plugins pour des technologies graphiques de plusieurs fabricants de matériel. Les développeurs balisent des ressources telles que les vecteurs de mouvement et les tampons de profondeur, puis positionnent la fonctionnalité demandée dans leur pipeline de rendu.

Cette voie donne à Nvidia un contrôle considérable sur la compatibilité. Le pilote peut identifier le matériel pris en charge, le plugin peut valider les entrées requises et l’entreprise peut mettre à jour le comportement du modèle. Les développeurs de jeux reçoivent également un contrat d’intégration construit autour d’API graphiques natives bien établies.

Un navigateur change chaque élément de cet agencement. JavaScript ne peut pas charger librement une DLL graphique propriétaire ni effectuer des appels arbitraires vers des pilotes natifs. Les applications de navigateur fonctionnent dans un bac à sable, avec un accès médiatisé par des interfaces standardisées.

WebGPU fournit la couche de calcul manquante. Son langage de shaders, WGSL, permet aux applications de définir des programmes que les navigateurs compilent pour le système sous-jacent. La spécification WGSL actuelle inclut des pipelines de calcul capables de traiter des tampons et des images dans des groupes de travail GPU parallèles.

En pratique, un développeur peut traduire les opérations d’un réseau neuronal en shaders de calcul. Les calculs matriciels, les convolutions, les passes d’échantillonnage et les transformations d’images peuvent alors s’exécuter sur n’importe quel GPU compatible exposé par le navigateur.

Cette traduction ne préserve pas l’intégralité de la pile logicielle de Nvidia. Elle la remplace par une nouvelle implémentation de calculs sélectionnés. Toute optimisation liée aux Tensor Cores, aux instructions propriétaires, à l’ordonnancement du pilote ou au runtime de Nvidia doit être reproduite différemment ou abandonnée.

Cela aide à expliquer l’écart de vitesse. La version officielle de Nvidia fonctionne sur du matériel RTX série 50 avec un pilote et une application conçus autour de cette fonctionnalité. La version de MAAN s’exécuterait à travers une abstraction de navigateur portable qui privilégie la compatibilité.

Nvidia affirme que DLSS 5 utilise un rendu neuronal guidé par la 3D pour améliorer l’éclairage et l’apparence des matériaux. Au lieu de simplement agrandir une image basse résolution, la fonctionnalité utilise les informations de la scène pour modifier l’apparence des surfaces, de la peau, des cheveux, des ombres et de la lumière.

Sa première vitrine officielle met l’accent sur les joueurs de basket-ball. Nvidia indique que le modèle améliore le passage de la lumière sous la surface à travers les oreilles, l’éclairage des poils du visage, les matériaux de peau et les ombres de contact. Le lancement de DLSS 5 de l’entreprise place ces effets dans le moteur de rendu natif de NBA 2K27.

La démo navigateur utilise un cadre plus étroit. Un utilisateur charge ou sélectionne un modèle, modifie les contrôles de présentation, puis attend le résultat neuronal. Cette charge de travail n’a pas à maintenir une simulation de jeu complète à une fréquence d’images interactive.

Cette différence ouvre la voie à des usages hors jeu. Les concepteurs de produits pourraient tolérer un court délai lors de la prévisualisation d’une ressource unique. Des architectes pourraient traiter une vue fixe avant de la présenter. Des artistes pourraient comparer différents traitements de matériaux sans installer un jeu pris en charge.

Ces possibilités restent des hypothèses, et non des produits validés. Le test disponible n’établit ni la précision sur des ressources professionnelles, ni des temps de rendu prévisibles, ni une prise en charge stable de scènes volumineuses. Il montre seulement pourquoi les exigences de latence déterminent si l’expérience a de la valeur.

WebGPU élargit également l’accès sans rendre toutes les machines équivalentes. Le projet GPU for the Web répertorie différentes combinaisons minimales de systèmes d’exploitation et de matériel dans ses conseils de compatibilité. Les navigateurs peuvent imposer des exigences plus strictes ou désactiver des appareils dotés de pilotes peu fiables.

Par conséquent, « fonctionne sur macOS » ne doit pas être interprété comme « fonctionne sur tous les Mac ». La version du navigateur, le système d’exploitation, la génération du GPU, la mémoire et les limites des fonctionnalités peuvent tous affecter l’exécution.

Le même problème apparaît sous Windows et Linux. Un navigateur compatible peut exposer WebGPU sur du matériel AMD, Intel ou Nvidia, mais le même shader peut emprunter des chemins différents dans le compilateur et le pilote de chaque fabricant.

Cette variabilité est le prix à payer lorsqu’on monte dans la pile d’abstraction. La voie officielle de Nvidia offre une cible étroite et optimisée. WebGPU offre une cible plus large, avec moins d’hypothèses sur le matériel sous-jacent.

La portabilité remet en cause le contrôle de Nvidia, pas ses performances

La confrontation principale oppose le déploiement contrôlé à l’exécution portable, et Nvidia conserve un avantage décisif en matière de performances.

La sortie officielle de DLSS 5 de Nvidia a commencé avec une combinaison limitée de matériel et de logiciels. NBA 2K27 prend en charge cette fonctionnalité sur les PC et ordinateurs portables GeForce RTX série 50. Les membres GeForce NOW Ultimate peuvent également y accéder via des systèmes cloud RTX de classe 5080 exploités par Nvidia.

L’entreprise exige un jeu pris en charge, un pilote approprié et du matériel compatible. Ce modèle rappelle les précédents déploiements de DLSS, dans lesquels Nvidia combinait des modèles entraînés avec des composants d’exécution propriétaires et une accélération propre aux RTX.

L’approche de MAAN supprimerait plusieurs de ces barrières. Elle n’exige ni NBA 2K27, ni une application Windows native, ni un GPU Nvidia. Elle demande plutôt si un navigateur et le GPU qu’il expose peuvent exécuter une reconstruction de la charge de travail neuronale.

Cela n’efface pas la contribution de Nvidia. Le modèle provient toujours de Nvidia, et son comportement utile découle du travail d’entraînement de Nvidia. Porter ses calculs vers WebGPU démontrerait la portabilité de l’inférence, non un remplacement indépendant du développement de modèles.

Cela ne rend pas non plus les restrictions officielles de matériel dénuées de sens. Nvidia vend une expérience avec une latence, un objectif de qualité et une structure de support spécifiques. La page navigateur propose actuellement une expérience sans garantie de service comparable.

Le contraste de performances est immense. Nvidia affirme qu’une RTX 5090 peut atteindre jusqu’à 370 images par seconde en 4K dans NBA 2K27 avec la suite DLSS complète et le ray tracing. Ce chiffre reflète un système, un préréglage et un ensemble précis de technologies DLSS ; il ne doit donc pas être comparé directement à une passe navigateur isolée.

Même avec cette réserve, plusieurs secondes par sortie ne peuvent pas répondre aux besoins d’un jeu interactif. À 60 images par seconde, le budget total par image est d’environ 16,7 millisecondes. Un passage neuronal d’une seconde consommerait environ 60 de ces budgets avant même que les autres tâches du jeu ne commencent.

La démonstration révèle plutôt une autre forme de pression. Elle pose la question de savoir si l’accès à un modèle graphique neuronal doit rester lié au mécanisme de diffusion prévu par le fournisseur dès lors que les poids et les opérations deviennent disponibles.

Des questions similaires entourent déjà l’intelligence artificielle exécutée dans le navigateur. Les développeurs font couramment tourner localement des modèles de langage, de vision et d’image via WebGPU. L’intérêt réside dans l’absence d’allers-retours vers un serveur, le maintien de certaines données sur l’appareil et la prise en charge de plusieurs systèmes d’exploitation avec une seule application.

Les modèles graphiques imposent des contraintes temporelles plus strictes. Un modèle de texte peut rester utile en générant progressivement des jetons. Un outil d’image peut rester utile si la création prend plusieurs secondes. Un jeu devient inconfortable lorsque le rendu dépasse son budget par image d’un ordre de grandeur.

Cela fait de DLSS 5 un test particulièrement exigeant pour le calcul dans le navigateur. Si le portage finit par approcher des vitesses interactives, il montrerait que WebGPU peut héberger des modèles de rendu sophistiqués sur plusieurs fournisseurs. S’il reste lent, il pourra tout de même servir aux aperçus hors ligne et à l’analyse technique.

Nvidia ne fait pas face à une menace concurrentielle immédiate de la part de cette démonstration. Les studios de jeux ne peuvent pas remplacer une intégration DLSS prise en charge par une page non officielle fondée sur des poids divulgués. Ils ont besoin de performances prévisibles, d’une clarté en matière de licences, d’une assurance qualité et d’un accès aux données du moteur.

Toutefois, le projet affaiblit une hypothèse plus simple : celle selon laquelle l’exécution du modèle neuronal exige intrinsèquement un GPU RTX. Le produit officiel peut nécessiter du matériel RTX, mais un réseau reconstruit peut apparemment fonctionner ailleurs lorsque la vitesse et le support ne sont plus prioritaires.

Cette distinction compte pour les développeurs qui évaluent de futurs systèmes de rendu neuronal. Un modèle peut être portable en théorie tout en restant spécifique à un matériel en production. Les accélérateurs spécialisés l’emportent lorsque la latence est déterminante, tandis que les API courantes l’emportent lorsque la portée compte.

L’avantage de Nvidia passe donc de l’exclusivité à l’optimisation. Son matériel, ses pilotes, ses outils de développement et son accès direct au modèle devraient maintenir la voie officielle plus rapide. L’expérience dans le navigateur teste la part de cet avantage qui relève de l’ingénierie d’exécution plutôt que d’une barrière absolue de compatibilité.

Les poids divulgués et l’absence de code laissent les principales questions sans réponse

La démonstration est techniquement évocatrice, mais ses lacunes en matière de provenance et de vérification l’empêchent de constituer une preuve nette de compatibilité DLSS indépendante.

MAAN aurait déclaré que le projet utilise des poids extraits d’une bibliothèque DLSS 5 divulguée. Le développeur aurait également indiqué qu’il n’était pas clair si cette bibliothèque différait de la version officielle.

Cette révélation modifie la nature de la réussite. Le projet ne semble pas recréer le modèle de Nvidia en entraînant une alternative indépendante. Il reconditionnerait plutôt les paramètres appris de Nvidia et mettrait en œuvre le processus d’inférence via WebGPU.

Les poids d’un modèle ne sont pas un ingrédient secondaire. Ils encodent les motifs appris pendant l’entraînement et déterminent en grande partie la sortie du réseau. Leur réutilisation préserve la partie la plus difficile à reproduire du système de Nvidia, même lorsque le code d’exécution est nouveau.

Cela soulève de potentielles questions de licence et de propriété intellectuelle. La disponibilité publique d’un fichier divulgué n’établit pas l’autorisation de redistribuer ou de déployer son contenu. Les informations disponibles n’identifient pas la position de Nvidia sur cette implémentation précise.

La publication prévue du code source constituera le premier test important. MAAN aurait indiqué que le code arriverait sur GitHub pendant le week-end suivant la démonstration initiale. D’ici là, les développeurs externes ne peuvent pas inspecter pleinement la manière dont les shaders correspondent au modèle revendiqué.

Le code source aiderait à répondre à plusieurs questions techniques. Les examinateurs pourraient identifier les opérateurs utilisés, confirmer si le traitement reste local, examiner les choix de précision et vérifier si la sortie correspond à l’implémentation officielle de Nvidia.

Il clarifierait également ce que signifie « DLSS 5 dans un navigateur ». L’expression pourrait décrire le modèle neuronal publié dans son intégralité, une reconstruction partielle ou un pipeline inspiré du réseau divulgué. Ces catégories sont matériellement différentes.

Des comparaisons d’images indépendantes compteront davantage que des captures d’écran sélectionnées par le développeur. Les testeurs ont besoin de scènes, de positions de caméra, d’entrées et de paramètres de sortie identiques. Ils devraient comparer le résultat dans le navigateur avec DLSS 5 officiel partout où une scène équivalente peut être construite.

La mesure de deux secondes de la démonstration nécessite également des tests plus larges. Un test sur un seul ordinateur de bureau RTX série 40 ne peut pas représenter le matériel Apple, AMD, Intel et Nvidia. Les performances peuvent varier selon la complexité du modèle, la résolution de sortie, le navigateur, le système d’exploitation et la compilation des shaders.

Le chargement initial mérite une analyse distincte. Télécharger 147MB est significatif sur des connexions limitées, mais cela diffère du temps nécessaire à chaque rendu. La mise en cache du navigateur pourrait réduire les coûts de démarrage ultérieurs, tandis que la pression mémoire pourrait encore limiter les appareils d’entrée de gamme.

La précision constitue une autre inconnue. Les modèles neuronaux utilisent souvent des formats à précision réduite pour améliorer la vitesse et l’efficacité mémoire. La prise en charge par WebGPU de certains types de données et opérations dépend des capacités du navigateur et du matériel, ce qui pourrait imposer des solutions de repli plus lentes.

La cohérence de l’image peut également différer selon les systèmes. L’exécution native de Nvidia utilise une combinaison connue de matériel et de pilotes. Une implémentation WebGPU traverse les compilateurs de shaders de plusieurs fournisseurs, ce qui peut produire de petites différences numériques ou des échecs de compatibilité plus importants.

La sécurité mérite un examen attentif, car la page accepte des fichiers 3D fournis par les utilisateurs. Un bac à sable de navigateur réduit l’accès de l’application au système, mais les modèles importés ou sélectionnés localement passent tout de même par du code d’analyse et de rendu. L’examen du code source peut révéler si les ressources restent locales ou quittent l’appareil.

Les utilisateurs devraient éviter de traiter la démonstration comme un outil de production fiable tant que ce comportement n’est pas clair. Les conceptions de produits confidentielles, les personnages non publiés et les plans architecturaux ne constituent pas des fichiers de test appropriés pour une page non auditée.

La question des poids divulgués peut également affecter la longévité du projet. Les hébergeurs ou plateformes de code peuvent répondre à des demandes légales valides. Même si l’implémentation reste en ligne, les futures mises à jour des modèles Nvidia pourraient rendre la version divulguée obsolète.

Aucune de ces préoccupations n’annule la leçon d’ingénierie. Réimplémenter une importante charge de travail graphique neuronale dans WebGPU resterait instructif. Elles limitent toutefois les affirmations plus fortes concernant la disponibilité, la légitimité et l’équivalence.

La conclusion correcte est plus restreinte. La démonstration montrerait que les opérations du modèle de Nvidia peuvent être exprimées via du calcul portable dans le navigateur. Elle n’a pas encore montré que le résultat est sous licence, complet, reproductible de manière indépendante ou adapté à une utilisation en temps réel.

Trois signaux détermineront si la démonstration compte

L’importance du projet dépend désormais de l’inspection du code, de benchmarks inter-fournisseurs et d’un cas d’usage crédible qui tire davantage parti de la portabilité que de la vitesse.

Le premier signal est la publication promise du code source. Un dépôt public permettrait aux développeurs graphiques d’inspecter les shaders de calcul WebGPU et de suivre le pipeline de traitement. Il révélerait également si le paquet de poids de 147MB est inclus, téléchargé séparément ou converti avant utilisation.

Une publication complète et reproductible renforcerait l’affirmation de portabilité. Les développeurs indépendants devraient pouvoir compiler le projet, exécuter les mêmes scènes et obtenir une sortie comparable. Une publication partielle omettant des composants essentiels du modèle laisserait l’affirmation centrale dépendre de la page hébergée par MAAN.

Le statut juridique du dépôt comptera autant que son contenu technique. Un retrait, une publication restreinte ou la suppression des poids affaiblirait la valeur du projet en tant qu’implémentation réutilisable. Cela n’effacerait pas la démonstration, mais limiterait sa validation ultérieure.

Le deuxième signal réside dans des benchmarks structurés entre fournisseurs de matériel. Les examinateurs devraient mesurer Apple Silicon, AMD Radeon, Intel Arc, les graphiques intégrés et plusieurs générations de RTX. Chaque test devrait distinguer le temps de téléchargement, la compilation des shaders, le premier rendu, les rendus ultérieurs, l’utilisation mémoire et la résolution de sortie.

Ces mesures montreront si le résultat de deux secondes relève d’un problème temporaire d’implémentation ou d’une limitation plus profonde. Une forte accélération après l’optimisation des shaders renforcerait l’argument en faveur du rendu neuronal dans le navigateur. Des performances stables entre versions optimisées orienteraient le projet vers les aperçus hors ligne.

Les mesures de qualité devraient accompagner la vitesse. Un portage rapide qui perd des détails de matériaux ou modifie la géométrie ne serait pas équivalent au système visé. Les images côte à côte doivent utiliser des entrées cohérentes et faire l’objet d’une inspection attentive de l’instabilité temporelle, des erreurs de texture et des artefacts d’éclairage.

Le troisième signal est l’adoption au-delà des démonstrations de nouveauté. Les aperçus architecturaux, les catalogues de produits numériques, les revues de personnages et la collaboration 3D dans le navigateur tolèrent tous davantage de latence que les jeux compétitifs. Ils bénéficient également de l’envoi d’un lien aux utilisateurs plutôt que de l’exigence d’une installation native.

Une application réelle aurait besoin de plus qu’un filtre impressionnant. Elle exigerait une sortie reproductible, des droits clairs sur le modèle, une prise en charge prévisible des navigateurs et une gestion sûre des ressources des clients. La démonstration actuelle de Nvidia DLSS 5 dans le navigateur n’a pas établi ces propriétés.

La réponse de Nvidia fournira un contexte complémentaire. L’entreprise pourrait ignorer l’expérience, contester son utilisation de ressources divulguées ou étendre l’accès officiel à davantage de matériel. Nvidia aurait déjà indiqué que la prise en charge des RTX série 40 arrivait, selon le reportage d’origine, ce qui réduit l’une des raisons de recourir à des solutions non officielles.

La propre feuille de route de l’entreprise pourrait également renforcer la spécialisation. Si les futures versions de DLSS s’appuient davantage sur des opérations spécifiques au matériel, les portages dans le navigateur pourraient rester possibles mais devenir de plus en plus lents. Si les architectures de modèles deviennent plus faciles à exprimer au moyen de shaders courants, les expériences portables devraient s’améliorer.

Pour les développeurs, la leçon immédiate n’est pas de remplacer DLSS natif par WebGPU. Il s’agit d’observer la frontière entre les modèles d’IA propriétaires et l’inférence locale standardisée. Le propriétaire du modèle contrôle l’entraînement et la distribution officielle, tandis que les API de calcul portables peuvent assouplir le contrôle sur les environnements où les charges de travail exposées s’exécutent.

Pour les utilisateurs, la démonstration offre une vision rare de cette frontière. Un moteur de rendu neuronal associé à une famille de GPU fonctionnerait via un navigateur sur plusieurs types de matériel. Pourtant, l’expérience sacrifie la vitesse qui rend DLSS utile au sein d’un jeu.

Ce compromis rend le projet digne d’intérêt sans le surestimer. Si le code devient reproductible, que les benchmarks s’améliorent et qu’un flux de travail non ludique légitime l’adopte, l’expérience indiquera la voie vers des graphismes neuronaux indépendants des fournisseurs. Si ces signaux ne se matérialisent pas, elle restera une démonstration ingénieuse construite autour de données de modèle divulguées.

Essayez la démonstration Nvidia DLSS 5 dans le navigateur uniquement avec des ressources non sensibles, notez les détails de votre navigateur et de votre matériel, et comparez les sorties plutôt que de vous fier à la seule compatibilité. La question décisive n’est plus de savoir si une image traitée peut apparaître sur un Mac. Elle est de savoir si une implémentation WebGPU ouverte, légale et reproductible peut fournir une qualité utile avant que le temps d’attente ne l’emporte sur sa portée plus large.