Le mod AMD BC-250 FSR 4 divise par deux le temps d’upscaling, mais le vrai test reste le gameplay

Le traitement AMD BC-250 FSR 4 est devenu nettement plus rapide, selon des benchmarks publiés avec une DLL FidelityFX développée par la communauté. En 1440p, le coût d’upscaling rapporté est passé de 11,51 millisecondes à 5,92 millisecondes. Cette réduction fait passer FSR 4 d’une expérimentation coûteuse à une option plus crédible pour cette carte inhabituelle basée sur RDNA.

Ce résultat est important, car le BC-250 n’a jamais été conçu comme un PC de jeu conventionnel. AMD a produit son processeur semi-personnalisé pour les systèmes de minage ASRock, en utilisant un silicium étroitement lié au processeur de la PlayStation 5. Des passionnés de Linux ont ensuite reconverti des cartes abandonnées en machines de jeu compactes grâce à des firmwares, pilotes, solutions de refroidissement et outils d’installation personnalisés.

Cette nouvelle version déplace le problème central de la compatibilité de base vers les performances réelles. Les précédents travaux d’optimisation dépendaient d’une pile graphique Mesa modifiée. La dernière implémentation intègre ses modifications dans une bibliothèque FidelityFX portable, que les utilisateurs peuvent installer aux côtés d’outils tels qu’OptiScaler et Proton.

Toutefois, les chiffres publiés mesurent l’upscaler lui-même, et non les performances complètes dans les jeux. Le développeur a publié des mesures synthétiques RC9, tandis que les nouveaux tests de gameplay restent limités. La réalisation mérite d’être examinée, mais sa valeur dépend encore de la stabilité, de la qualité d’image et des résultats dans des jeux réels.

Le traitement AMD BC-250 FSR 4 diminue à trois résolutions

La version RC9 réduit d’environ moitié le coût mesuré de FSR 4.1.1 en 1080p, 1440p et 4K.

Le résultat le plus important provient d’une sortie en 2560 x 1440 utilisant une entrée Quality de 1706 x 960. Les shaders FSR 4.1.1 d’origine auraient nécessité 11,51 millisecondes pour l’ensemble de l’exécution d’upscaling. La version 4.0.0-rc9 a réalisé la même charge de travail mesurée en 5,92 millisecondes.

Cela représente une réduction d’environ 49 %. Cela restitue également près de 5,6 millisecondes au reste du pipeline de rendu. Cette différence est considérable lorsqu’un jeu visant 60 images par seconde ne dispose que de 16,67 millisecondes par image.

Les autres résolutions enregistrées suivent le même schéma. En 1920 x 1080, le temps de traitement est passé de 7,13 millisecondes à 3,93 millisecondes. En 3840 x 2160, il est passé de 25,72 millisecondes à 12,08 millisecondes.

Ces résultats correspondent à des réductions d’environ 45 % et 53 %, respectivement. L’amélioration ne semble donc pas limitée à une seule taille de sortie. Les gains absolus augmentent avec la résolution de sortie, à mesure que l’upscaler traite davantage de pixels.

La version RC9 du développeur intègre le code optimisé sous la forme de amd_fidelityfx_upscaler_dx12.dll. Cette bibliothèque agit comme fournisseur d’upscaling FidelityFX dans les chemins d’intégration pris en charge. Elle remplace le composant d’upscaling concerné sans exiger l’ancienne compilation Mesa personnalisée.

Selon le résumé des tests publié, ces chiffres représentent des coûts isolés d’exécution de FSR. Ils ne mesurent ni le temps de rendu complet d’une image ni les performances moyennes dans les jeux. Le travail du CPU, le rendu du jeu, la compilation des shaders, les couches de traduction et la synchronisation de l’affichage restent hors de cette mesure.

Cette distinction empêche de convertir directement les millisecondes économisées en images gagnées. Un jeu limité par son CPU pourrait afficher peu d’amélioration. Un jeu fortement limité par le GPU pourrait en bénéficier davantage, surtout lorsque la précédente passe d’upscaling absorbait une grande part du budget par image.

Malgré tout, ces chiffres répondent à un obstacle précis. Faire fonctionner FSR 4 sur le BC-250 était techniquement possible avant RC9, mais l’upscaler pouvait consommer l’essentiel du budget d’une image à fréquence de rafraîchissement élevée. Réduire cette charge presque de moitié rend des tests plus larges pertinents.

La version modifie donc la question. La communauté n’a plus seulement à se demander si FSR 4 peut s’exécuter sur cette carte. Elle peut désormais se demander si le chemin optimisé améliore suffisamment l’expérience de jeu complète pour justifier son installation.

Une DLL FidelityFX portable remplace la voie Mesa personnalisée

Le progrès central est la portabilité, car l’optimisation accompagne désormais l’upscaler au lieu d’un pilote graphique spécialisé.

L’optimisation BC-250 d’origine ciblait Mesa, la pile graphique open source couramment utilisée par les systèmes Linux. Elle modifiait la gestion par le pilote Vulkan RADV des opérations INT8 utilisées par FSR 4. INT8 désigne l’arithmétique entière sur huit bits, utilisée par les modèles d’apprentissage automatique pour réduire les coûts de traitement et de mémoire.

Ce travail répondait à une limitation inhabituelle du processeur graphique GFX1013 du BC-250. La carte peut exécuter la charge de travail requise, mais son chemin de produit scalaire d’entiers signés empaquetés offre de faibles performances. Un produit scalaire combine plusieurs multiplications et additions, ce qui en fait une opération courante dans les modèles neuronaux de traitement d’image.

Le projet précédent a remplacé ce chemin coûteux par une séquence mieux adaptée au BC-250. Son dépôt décrit une compilation Mesa expérimentale qui utilise des instructions entières alternatives au lieu de s’appuyer sur le chemin natif problématique. La modification ciblait un identifiant de périphérique précis et un ensemble de shaders validé.

Cette approche a démontré l’opportunité en matière de performances, mais elle plaçait le déploiement dans la pile de pilotes. Les utilisateurs avaient besoin d’une compilation Mesa dédiée et devaient lancer les jeux avec la configuration Vulkan appropriée. Les modifications de pilotes entraînent aussi des coûts de maintenance lorsque Mesa, Proton ou une distribution Linux évolue.

L’implémentation portable déplace l’optimisation dans la DLL FidelityFX. L’upscaler devient ainsi un composant remplaçable plutôt qu’une variante de pilote à l’échelle du système. Les utilisateurs peuvent placer la bibliothèque dans un jeu pris en charge ou une configuration d’adaptateur, puis la retirer sans recompiler Mesa.

Le guide d’installation du projet indique que RC9 ne nécessite ni l’ancien outil de compatibilité ni une installation de pilote spéciale. Son périmètre testé reste le matériel BC-250 exécutant Linux via Proton classique. Proton est la couche de compatibilité de Valve permettant d’exécuter des jeux Windows sous Linux.

OptiScaler peut servir d’adaptateur entre un jeu et la bibliothèque FidelityFX. Il intercepte un chemin d’upscaling disponible, puis fournit le backend sélectionné. Le menu d’un jeu peut encore afficher DLSS, FSR ou XeSS, même lorsque le fournisseur FidelityFX injecté effectue l’upscaling final.

Cette organisation offre de la flexibilité, mais elle ajoute aussi des variables de configuration. Le jeu doit fournir une entrée temporelle compatible, c’est-à-dire les vecteurs de mouvement et les autres données d’image nécessaires à la reconstruction d’une image de plus haute résolution. La DLL seule ne peut pas ajouter ces informations à un titre qui ne les produit jamais.

Les utilisateurs doivent également vérifier que RC9 est le fournisseur actif. Le projet recommande d’activer le filigrane intégré et de contrôler la présence des libellés FSR-INT8, 4.1.1R9 et de source locale. Une somme de contrôle confirme le fichier installé, tandis que le filigrane rendu vérifie quel fournisseur a traité l’image.

C’est important, car plusieurs composants d’upscaling peuvent coexister dans un préfixe Proton ou un répertoire de jeu modifié. Les mises à jour automatiques de pilotes, les fichiers OptiScaler existants et les correctifs de jeu peuvent restaurer silencieusement une autre bibliothèque. Un menu fonctionnel ne prouve pas que le modèle optimisé rend la scène.

La portabilité ne signifie donc pas compatibilité universelle. Elle signifie que l’optimisation a été déplacée vers un package plus facile à installer, vérifier, remplacer et restaurer. Il s’agit d’une amélioration opérationnelle majeure pour un projet communautaire bâti autour de matériel non pris en charge.

Pourquoi le BC-250 fait de ce résultat bien plus qu’une curiosité de modding

L’upscaler plus rapide prolonge un effort plus large visant à récupérer du matériel de jeu utile à partir d’un produit de minage spécialisé.

Le BC-250 associe un CPU Zen 2 à six cœurs et 12 threads à un processeur graphique GFX1013 intégré. Les cartes d’origine exposent 24 unités de calcul et intègrent 16 Go de mémoire unifiée GDDR6. Contrairement à un ordinateur de bureau classique, le système ne repose pas sur des modules de mémoire DDR séparés.

La documentation matérielle de la communauté décrit la carte comme une conception de minage personnalisée, dotée d’un format non standard. Le matériel d’encodage et de décodage vidéo est indisponible, et les boîtiers ou refroidisseurs PC ordinaires ne s’adaptent pas sans modification. La connectivité de stockage est également plus limitée que sur une carte mère classique.

Le processeur provient de la même grande famille de silicium semi-personnalisé associée à la PlayStation 5 de Sony. Toutefois, présenter le BC-250 comme une PS5 de bureau exagérerait ce lien. Ses cœurs CPU activés, sa configuration graphique, son firmware, ses entrées-sorties et son environnement d’exploitation diffèrent de ceux de la console.

La carte est arrivée sur le marché des passionnés après l’affaiblissement de la demande liée au minage de cryptomonnaies. Des moddeurs ont ensuite développé des correctifs de firmware, une prise en charge des pilotes Linux, des contrôles de ventilateurs, des boîtiers et des distributions orientées jeu. Chaque amélioration a supprimé une limitation d’un matériel dépourvu de canal de support grand public normal.

Des projets précédents ont établi que la configuration d’origine pouvait exécuter des jeux PC exigeants sous Linux. Des membres de la communauté ont ensuite expérimenté la restauration de cœurs CPU désactivés et l’exposition d’un plus grand nombre d’unités de calcul graphiques physiques sur des processeurs compatibles. Ces modifications dépendent de la puce et ne fonctionnent pas sur toutes les cartes.

FSR 4 ajoute une nouvelle couche à cet effort de récupération. Le SDK FSR actuel d’AMD combine des données spatiales et temporelles avec des modèles d’apprentissage automatique afin de reconstruire des images de plus haute résolution. Il cible des plateformes graphiques plus récentes via des implémentations officiellement prises en charge, tandis que la prise en charge du BC-250 provient de l’ingénierie communautaire.

La tension est évidente. FSR 4 promet une meilleure qualité d’image reconstruite que les anciens upscalers, mais son modèle entraîne un coût de traitement significatif. Sur une carte limitée, l’upscaler peut annuler les performances gagnées en effectuant le rendu avec une résolution d’entrée inférieure.

En 1440p, le coût initial de 11,51 millisecondes consommait environ 69 % du budget d’une image à 60 fps. Ce calcul ne couvre que l’exécution de FSR. Le jeu avait encore besoin de temps pour la géométrie, l’éclairage, les effets, la simulation CPU, le travail du pilote et la présentation finale.

RC9 ramène cette part à environ 36 %. Le nouveau chiffre reste coûteux, mais il laisse beaucoup plus de place au jeu lui-même. En 4K, la réduction de 25,72 millisecondes à 12,08 millisecondes fait passer l’upscaler sous le budget complet d’une image à 60 fps.

Cela ne rend pas probable le jeu en 4K à 60 fps sur le BC-250. Le reste de la charge de travail nécessite toujours du temps de traitement, et les performances graphiques de la carte restent limitées. Cela montre toutefois pourquoi l’optimisation de l’upscaler compte davantage que le simple fait de parvenir à le lancer.

Le projet AMD BC-250 FSR 4 illustre également la valeur des composants Linux ouverts. Les développeurs ont pu examiner le comportement des shaders, identifier le chemin d’instructions coûteux, tester des alternatives et empaqueter le résultat. Ce processus serait plus difficile dans une chaîne de pilotes et d’applications entièrement fermée.

Le projet dépend toutefois en partie de rétro-ingénierie et d’intégrations tierces. AMD n’a pas présenté RC9 comme une version officielle pour le BC-250. Les utilisateurs doivent considérer la DLL comme un logiciel expérimental destiné à un appareil de niche, et non comme une fonctionnalité prise en charge des pilotes Radeon.

Le véritable adversaire est la compatibilité sans performances pratiques

RC9 remet en cause l’écart entre faire fonctionner FSR 4 et le rendre utile dans l’image complète d’un jeu.

Les démonstrations de compatibilité produisent souvent des captures d’écran convaincantes. Une fonctionnalité se charge, un filigrane apparaît et le matériel affiche une image que son fournisseur n’a jamais officiellement prise en charge. Cela prouve un accès technique, mais en dit peu sur la latence, la stabilité ou la fluidité durable en jeu.

Le BC-250 avait déjà franchi le seuil de compatibilité. Des travaux antérieurs de la communauté ont montré que FSR 4.1.1 pouvait s’exécuter via la pile graphique Linux de la carte. Le problème venait du temps consommé par ses shaders d’apprentissage automatique, en particulier les opérations sur entiers empaquetés signés.

En 1440p, une passe d’upscaling de 11,51 millisecondes exerce une forte pression sur tout objectif de performances. Une image à 30 fps dispose de 33,33 millisecondes, ce qui rend cette surcharge plus facile à absorber. Un objectif de 60 fps n’accorde que la moitié de ce temps, tandis que 120 fps n’en laisse que 8,33 millisecondes.

Le résultat de 5,92 millisecondes de RC9 tient à lui seul dans le budget d’une image à 120 fps. Le jeu complet n’y tient évidemment plus une fois tous les autres traitements pris en compte. Néanmoins, le dispatch optimisé ne dépasse plus ce budget total avant même que le jeu n’ait rendu quoi que ce soit d’autre.

C’est le renversement central du projet. FSR améliore normalement les performances en permettant à un jeu de rendre moins de pixels. Sur le chemin BC-250 non optimisé, le processus de reconstruction pouvait consommer une grande partie du temps économisé. La solution apportée par la fonctionnalité risquait de devenir un nouveau goulot d’étranglement.

La DLL optimisée réduit cette contradiction. Elle ne supprime pas le coût, mais elle resserre l’écart entre prise en charge théorique et performances réellement exploitables. Cela donne aux développeurs et aux utilisateurs davantage de latitude pour comparer FSR 4 à FSR 3, XeSS ou à une résolution native plus basse.

Ces comparaisons exigent des contrôles rigoureux. Chaque upscaler emploie une logique de reconstruction différente et peut proposer des modes de qualité distincts. Un réglage Quality dans une implémentation ne correspond pas nécessairement à la résolution d’entrée, à la netteté ou au comportement visuel d’un autre.

La qualité d’image compte également davantage que le seul temps de dispatch. Un shader plus rapide a peu de valeur s’il introduit de l’instabilité, du ghosting, du scintillement, des erreurs de désocclusion ou des éléments d’interface défaillants. Ces problèmes apparaissent souvent en mouvement plutôt que sur des captures statiques.

Le même problème s’applique aux fréquences d’images moyennes. Un benchmark peut afficher une moyenne plus élevée tout en souffrant d’une distribution irrégulière des images. Les percentiles de frame time et les saccades visibles déterminent souvent si un jeu paraît réellement amélioré.

RC9 doit donc rivaliser avec des options plus simples. Les utilisateurs peuvent choisir une ancienne implémentation de FSR moins coûteuse, réduire les réglages natifs ou accepter une fréquence d’images inférieure. Le chemin FSR 4 optimisé ne l’emporte que lorsque son gain de qualité d’image justifie la surcharge restante et la complexité d’installation.

Le projet n’a pas besoin de surpasser toutes les alternatives. Un outil communautaire peut être utile s’il améliore une poignée de jeux exigeants sur un appareil donné. Ce standard plus restreint doit toutefois rester explicite lors de l’interprétation du benchmark.

C’est pourquoi la DLL portable compte autant que le chiffre mis en avant. Une installation plus simple réduit le coût des comparaisons réelles. Davantage d’utilisateurs peuvent tester le même binaire, rapporter des résultats reproductibles et identifier les titres pour lesquels le compromis fonctionne.

Ce que le benchmark n’établit pas encore

Les données publiées montrent un dispatch d’upscaling plus rapide, mais elles n’établissent pas encore une qualité visuelle équivalente ni des gains prévisibles d’un jeu à l’autre.

La première incertitude concerne l’étendue des tests. La documentation du projet indique que ses sept vérifications de jeux enregistrées utilisaient une version RC7 antérieure. RC9 dispose d’une validation synthétique et d’une configuration Cyberpunk 2077 installée, mais le guide ne revendique pas une nouvelle série de tests en jeu avec RC9 pour tous les titres.

Cette lacune n’invalide pas le benchmark. Les tests synthétiques isolent l’upscaler et facilitent les comparaisons avant/après. Ils répondent simplement à une question plus limitée qu’un benchmark en jeu.

Une évaluation complète nécessite des fréquences d’images moyennes, des résultats de one-percent-low et des graphiques de frame time issus de scènes reproductibles. Elle doit aussi comparer des résolutions d’entrée et de sortie identiques. Sans ces contrôles, les variations du CPU ou des changements de rendu non liés peuvent masquer l’effet de la DLL.

La deuxième incertitude concerne l’équivalence visuelle. Le benchmark indique que le chemin optimisé traite la charge de travail plus rapidement. Il n’établit pas indépendamment que chaque pixel de sortie correspond au chemin original d’AMD ni que le comportement temporel reste inchangé pendant le jeu.

Les upscalers d’apprentissage automatique peuvent échouer de manière spécifique à certaines scènes. Les détails géométriques fins peuvent scintiller, les effets transparents peuvent se dégrader, les particules peuvent laisser des traînées et les surfaces nouvellement révélées peuvent afficher des erreurs de reconstruction. Les mouvements rapides de caméra révèlent souvent des problèmes qu’une capture fixe dissimule.

Le troisième enjeu est la compatibilité avec les jeux. OptiScaler fournit plusieurs chemins d’injection, mais chaque jeu expose des API et des données temporelles différentes. Les systèmes anti-triche, les launchers, les mises à jour et les changements de moteur de rendu peuvent empêcher une installation pourtant correcte de fonctionner.

Les intégrations natives de FidelityFX varient également. Un jeu documenté nécessite une bibliothèque de chargement renommée précisément, tandis qu’un autre utilise un backend OptiScaler. Le projet déconseille explicitement d’appliquer le remplacement de fichiers d’un titre à des jeux sans rapport.

La quatrième incertitude concerne le périmètre de la plateforme. RC9 cible le matériel BC-250 sous Linux avec Proton. Le guide ne promet pas de prise en charge de Windows natif ni d’autres GPU. Une DLL portable est plus facile à déplacer, mais la portabilité du fichier ne prouve pas la portabilité de son comportement optimisé.

L’implémentation est également un logiciel tiers non signé. Les utilisateurs doivent l’obtenir depuis la version indiquée, vérifier sa somme de contrôle et conserver des sauvegardes des fichiers remplacés. Les mises à jour des jeux peuvent écraser la bibliothèque ou créer des incompatibilités nécessitant un retour en arrière.

Les implications plus larges pour RDNA 2 restent particulièrement incertaines. Le BC-250 utilise un processeur GFX1013 inhabituel doté d’un comportement d’instructions spécifique. Une solution de contournement qui aide cet appareil ne peut pas prédire automatiquement les performances sur les cartes Radeon RX 6000, le matériel Steam Deck ou les processeurs de console.

Le benchmark rapporté provient également d’un petit écosystème de modding. Une reproduction indépendante devrait confirmer les chiffres sur différentes cartes, fréquences, versions de firmware et conditions thermiques.

Les conditions thermiques méritent une attention particulière, car des charges de shaders soutenues peuvent se comporter différemment de tests brefs. Une carte insuffisamment refroidie peut réduire ses fréquences après une session de jeu prolongée. Cela pourrait réduire ou masquer le bénéfice de performances observé lors d’un bref test synthétique.

Les variations entre cartes ajoutent une autre complication. Certains processeurs BC-250 tolèrent des cœurs ou unités de calcul déverrouillés, tandis que d’autres ne restent stables que dans leur configuration d’origine. Les benchmarks doivent clairement identifier le matériel activé, les fréquences, les limites de puissance, le firmware, la version de Mesa et la build de Proton.

Aucune de ces limites n’efface la réduction rapportée. Elles définissent ce que les preuves actuelles permettent d’affirmer. RC9 semble rendre le dispatch FSR nettement plus rapide sur son système cible, tandis que sa valeur dans les jeux complets reste une affirmation à tester.

Cette lecture prudente sert mieux le projet que de présenter le résultat comme une prise en charge universelle de FSR 4. Des limites claires aident les utilisateurs à reproduire le travail et les développeurs à identifier les problèmes nécessitant encore une intervention d’ingénierie.

Trois signaux montreront si RC9 transforme le jeu sur BC-250

La prochaine phase doit relier l’efficacité synthétique à une expérience de jeu reproductible, une stabilité visuelle et une distribution maintenable.

Le premier signal est une suite de benchmarks RC9 en jeu contrôlée. Cyberpunk 2077 et Control constituent des points de départ pertinents, car le projet documente déjà des chemins d’installation pour les deux. Les tests devraient comparer les shaders d’origine, RC9 et un ancien upscaler avec des réglages identiques.

Les rapports les plus utiles incluront les performances moyennes et les percentiles de frame time. Ils devraient enregistrer le temps d’image complet en plus du coût isolé de FSR. Si RC9 produit des gains constants dans les scènes limitées par le GPU, la conclusion actuelle fondée sur le mécanisme deviendra bien plus solide.

Si les performances globales en jeu changent à peine, le benchmark apprendra tout de même quelque chose aux développeurs. Cela indiquerait qu’une autre partie du pipeline de rendu domine. L’optimisation pourrait rester techniquement efficace sans améliorer matériellement un jeu donné.

Le deuxième signal est une validation indépendante de la qualité d’image. Les utilisateurs devraient capturer les mouvements, la géométrie fine, les particules, les reflets, les éléments d’interface et les surfaces désoccluses. Les comparaisons nécessitent des trajectoires de caméra et des résolutions d’entrée identiques plutôt que des captures sans rapport.

Une correspondance stable avec la sortie originale renforcerait l’affirmation selon laquelle RC9 offre une reconstruction presque identique à un coût bien moindre. Un ghosting ou scintillement récurrent affaiblirait son intérêt pratique, même si l’avantage de timing demeure.

Le troisième signal est l’adoption via des paquets Linux maintenus et des outils d’installation. La DLL réduit déjà la dépendance à une build Mesa personnalisée. Une intégration continue dans les distributions BC-250, les workflows Proton et les paquets verrouillés par somme de contrôle rendrait les tests plus reproductibles.

Un projet Linux propose déjà le fork comme option expérimentale d’OptiScaler tout en avertissant que les builds non signées ne constituent pas des recommandations. Ce cadrage est approprié. Un empaquetage reproductible peut rendre un logiciel expérimental plus sûr sans le transformer en prise en charge officielle.

La maintenance après les mises à jour de jeux, de Proton et de pilotes révélera si la portabilité résiste à l’usage réel. Une bibliothèque de remplacement qui se casse fréquemment impose un coût caché. Un paquet stable avec des instructions de retour en arrière claires transformerait l’optimisation en infrastructure pratique.

La réponse d’AMD importe moins à court terme, mais la prise en charge officielle reste à surveiller. L’entreprise contrôle le développement de FSR et les chemins Radeon pris en charge. Les découvertes de la communauté peuvent révéler une demande, mais elles ne garantissent pas qu’AMD prendra en charge ce processeur issu du minage.

Pour les propriétaires de BC-250, la prochaine étape raisonnable consiste en une expérimentation mesurée. Vérifiez le fichier de la version, conservez les bibliothèques d’origine, confirmez le filigrane rendu et mesurez une scène reproductible. Comparez le comportement visuel avant de décider si la surcharge restante en vaut la peine.

Pour les développeurs graphiques, le projet offre une leçon plus générale sur les hypothèses logicielles. Un modèle conçu autour d’un matériel entier plus récent peut mal se comporter sur un processeur inhabituel, même lorsque ce processeur exécute les instructions requises. Un travail ciblé sur les shaders peut récupérer des performances qu’un chemin générique laisse inexploitées.

Le résultat AMD BC-250 FSR 4 est donc prometteur pour une raison précise. Il transforme une expérimentation spécialisée sur les pilotes en paquet portable et réduit de près de moitié la charge de travail mesurée. Il n’établit ni une prise en charge universelle ni des gains de fréquence d’images garantis.

Les preuves décisives devraient venir de jeux ordinaires plutôt que d’un autre chiffre isolé. RC9 améliore-t-il la régularité des images dans les scènes exigeantes tout en préservant des détails reconstruits stables ? Des réponses reproductibles à cette question détermineront si cette DLL devient un élément durable du jeu sur BC-250 ou reste une démonstration technique impressionnante.