La couverture des shaders d'AnyPS5 atteint 100 %, mais les jeux PS5 natifs sur PC restent lointains

La couverture des shaders d'AnyPS5 a atteint 100 % sur 1 166 instructions GPU suivies, offrant à ce projet open source une étape technique majeure assortie d'une limite importante. Chaque instruction répertoriée peut désormais être reconnue, mais cette reconnaissance ne garantit ni une traduction correcte ni un rendu fiable des jeux.

Cette distinction sépare une avancée d'ingénierie précieuse de l'affirmation plus spectaculaire selon laquelle les jeux PlayStation 5 sont prêts à fonctionner nativement sur des PC ordinaires. AnyPS5 doit encore résoudre des sémantiques de shaders inachevées, des bibliothèques système incomplètes, des problèmes de synchronisation et des comportements propres à certains titres.

Le projet emprunte également une voie différente de celle d'émulateurs expérimentaux tels que SharpEmu et Kyty. Au lieu de maintenir un environnement de console virtuelle, AnyPS5 convertit les exécutables pour Windows ou Linux et fournit des bibliothèques système de remplacement. Ses progrès mettent donc à l'épreuve une idée plus large : celle de savoir si les logiciels PS5 peuvent être adaptés davantage comme une charge de travail de couche de compatibilité que comme une console traditionnellement émulée.

La couverture des shaders d'AnyPS5 inclut désormais 1 166 instructions

Cette nouvelle étape comble une lacune dans le décodeur de shaders d'AnyPS5, et non tous les obstacles entre un exécutable PS5 et un jeu PC fonctionnel.

Un instantané des progrès daté du 9 octobre 2026 indique que 1 166 des 1 166 instructions GPU suivies sont implémentées. La liste s'appuie sur les jeux d'instructions AMD RDNA 1 et RDNA 2 et couvre plusieurs familles d'instructions utilisées dans les programmes de shaders.

Ces familles comprennent des opérations scalaires, des opérations vectorielles, des accès mémoire, le traitement d'images, le partage de données et des instructions de contrôle de flux. Ensemble, elles constituent une grande partie du vocabulaire utilisé par les programmes graphiques de la PlayStation 5 pour piloter le GPU AMD de la console.

AnyPS5 utilise une définition particulière d'« implémentée » pour cet indicateur. Une instruction est admissible lorsque le décodeur de shaders la reconnaît. Le décodeur est le composant qui lit une instruction machine et identifie son opération, ses opérandes et son encodage.

La reconnaissance est importante, car une instruction inconnue peut interrompre immédiatement le processus de traduction. L'outil ne peut pas convertir un shader s'il ne peut pas déterminer la signification d'une partie du programme d'origine.

Toutefois, reconnaître une instruction diffère de la reproduction de son comportement. Cette dernière exige de traduire sa sémantique en code produisant les mêmes résultats via une pile graphique PC.

Selon la documentation publique du projet, son recompileur de shaders produit du SPIR-V. SPIR-V est une représentation intermédiaire qui permet aux outils d'exprimer des programmes GPU pour des API, dont Vulkan, sans cibler directement le code machine d'un fournisseur donné.

Le projet indique que sa sortie générée peut être vérifiée avec SPIRV-Tools lorsqu'une option de validation dédiée est activée. Cette validation peut détecter des modules mal formés et des violations structurelles. Elle ne prouve pas que chaque instruction traduite renvoie le résultat exact attendu par un jeu PS5.

La différence ressemble à l'analyse d'un dictionnaire technique complet plutôt qu'à la traduction correcte de chaque phrase possible. Un traducteur doit d'abord reconnaître chaque mot, mais la couverture du vocabulaire ne résout pas à elle seule le contexte, le timing ou les comportements ambigus.

Le rapport de couverture indique également que l'implémentation des bibliothèques système suivies atteint 2 575 des 3 038 fonctions déclarées, soit 84,76 %. Ce chiffre appelle sa propre réserve.

Il mesure les fonctions déjà connues et déclarées par le projet. Le dénominateur peut augmenter lorsque les développeurs découvrent des fonctions supplémentaires nécessaires à davantage de jeux. Il ne s'agit pas d'un pourcentage fixe de l'interface logicielle privée complète de Sony.

Le chiffre des shaders est plus concret dans le périmètre indiqué. Chaque instruction actuellement incluse dans la liste de suivi RDNA du projet atteint désormais le seuil de reconnaissance. Cela laisse aux contributeurs moins d'impasses immédiates lorsqu'ils examinent des shaders inconnus.

Cela modifie également le travail à venir. Les développeurs peuvent de plus en plus passer du comblement des entrées manquantes du décodeur aux tests de sémantique, au diagnostic des échecs de rendu et à la comparaison des sorties avec le comportement attendu du matériel.

Ce changement fait de 100 % une étape significative. Il n'en fait simplement pas un verdict de compatibilité.

Comment AnyPS5 fonctionne sans émulateur traditionnel

AnyPS5 parie que les fondations familières x86-64 et graphiques AMD de la PS5 rendent la conversion plus pratique que la reconstruction complète de la console en logiciel.

L'architecture du projet commence par un avantage matériel. La PlayStation 5 utilise un processeur AMD fondé sur le jeu d'instructions x86-64, également employé par les PC Windows et Linux grand public.

Les anciennes consoles reposaient souvent sur des architectures CPU très différentes du matériel de bureau. Exécuter leurs logiciels nécessitait une traduction continue des instructions ou une simulation détaillée de processeurs peu familiers.

AnyPS5 adopte une autre approche. Sa présentation du projet décrit un outil destiné à porter automatiquement des exécutables vers Linux et Windows. Un relinker convertit l'exécutable d'origine dans un format natif pour le système d'exploitation cible.

Le relinking traite de la structure et des dépendances de l'exécutable. Un programme PS5 attend des modules, interfaces et comportements de chargement propres à Sony qui n'existent pas dans une installation PC standard.

AnyPS5 fournit donc des remplacements pour les bibliothèques système PRX de la PS5. Les bibliothèques PRX sont des modules exécutables qui exposent des fonctions du système d'exploitation et de l'environnement d'exécution utilisées par les logiciels de console.

L'application convertie établit des liens avec ces implémentations de remplacement. En théorie, le jeu peut alors fonctionner comme un processus hôte natif plutôt qu'à l'intérieur d'un processus d'émulation distinct.

Les graphismes suivent une voie de conversion parallèle. Le recompileur de shaders décode les instructions GPU et génère du SPIR-V pour Vulkan, une API graphique multiplateforme prise en charge par Windows et Linux.

Cette architecture explique pourquoi la reconnaissance complète des instructions est importante. Tout shader contenant un encodage inconnu crée une faille dans la chaîne de conversion. Compléter la liste suivie permet au décodeur d'aller plus loin avant de rencontrer une autre catégorie d'échec.

Elle explique aussi pourquoi cette étape reste incomplète. Un décodeur peut identifier correctement une instruction tandis que le recompileur ne dispose pas encore d'une traduction SPIR-V finalisée de son comportement.

Même une traduction générée peut être subtilement erronée. Les règles de virgule flottante, l'ordonnancement mémoire, le masquage des lanes, les opérations de wave, l'échantillonnage de textures et les comportements matériels non définis peuvent produire des défauts qui n'apparaissent que dans certaines charges de travail.

Les jeux sur console dépendent également de davantage que du code CPU et des shaders. Ils attendent des dispositions mémoire spécifiques, des règles de synchronisation, un comportement des commandes graphiques, des services audio, des interfaces de stockage, les entrées de la manette, le timing et les réponses du système d'exploitation.

Un exécutable natif peut échouer parce qu'une fonction attendue est absente. Il peut aussi échouer parce qu'une fonction existante renvoie une valeur légèrement différente, gère incorrectement un cas limite ou termine un travail dans le mauvais ordre.

Les règles de contribution du projet reconnaissent cette difficulté. Les modifications de shaders doivent indiquer si leur sémantique provient de la documentation AMD, de Mesa, de LLVM, de mesures matérielles ou d'une autre source technique précise.

La politique de contribution indique que les réviseurs vérifient la sémantique des shaders par rapport au matériel. Les comportements qui restent incertains doivent générer une erreur ou être inscrits au registre de dette technique du projet.

Cette politique traduit une préférence délibérée pour un échec visible plutôt qu'une approximation silencieuse. Un plantage explicite peut révéler le comportement manquant. Un stub discret mais inexact peut corrompre l'état et produire des résultats trompeurs beaucoup plus tard.

AnyPS5 ne se contente donc pas de modifier des extensions de fichiers. Il reconstruit une part suffisante de l'environnement logiciel de la PS5 afin que les programmes convertis se comportent correctement sur un autre système d'exploitation.

Le relinker, les bibliothèques de remplacement et le recompileur de shaders forment une seule chaîne. Les progrès de n'importe quel composant ne comptent que lorsque la chaîne entière peut prendre en charge un véritable titre.

Le véritable enjeu oppose couverture et exactitude

Le conflit central n'oppose pas AnyPS5 à Sony, ni même le portage à l'émulation. Il oppose le pourcentage de couverture visible du projet à la norme bien plus exigeante de l'exactitude comportementale.

Un tableau de bord des progrès condense un travail complexe en chiffres lisibles. Il aide les contributeurs à localiser les domaines manquants et donne aux observateurs un moyen de suivre un projet évoluant rapidement.

Le risque apparaît lorsqu'un indicateur d'ingénierie interne devient une affirmation publique de compatibilité. « 100 % de couverture des instructions de shaders GPU » semble proche de « prise en charge GPU complète », bien que les deux énoncés décrivent des seuils différents.

La couverture répond à la question de savoir si le décodeur connaît l'existence d'une instruction. L'exactitude demande si le shader traduit dans son ensemble se comporte comme l'original dans toutes les conditions pertinentes.

Cette seconde question intervient à plusieurs niveaux. L'instruction doit produire les bonnes valeurs, interagir correctement avec les instructions voisines et préserver les hypothèses du jeu concernant l'ordre d'exécution.

Ensuite, le shader doit s'intégrer aux liaisons de ressources, aux textures, aux buffers, aux cibles de rendu et au flux de commandes. Une opération autonome correcte peut encore échouer au sein d'une chaîne graphique incomplète.

Enfin, le résultat doit rester stable sur les GPU et pilotes hôtes. Vulkan réduit les différences entre plateformes grâce à une API commune, mais il n'efface pas tous les détails d'implémentation.

La validation SPIR-V joue un rôle tout aussi limité. Un validateur peut confirmer qu'un module respecte des règles structurelles formelles. Il ne peut pas déterminer si le programme représente le shader PS5 attendu.

Une phrase grammaticalement valide peut tout de même énoncer un fait erroné. De la même manière, un module SPIR-V valide peut être compilé et exécuté tout en produisant une image incorrecte.

Cette distinction devient particulièrement importante pour les jeux commerciaux exigeants. Les titres modernes utilisent de vastes combinaisons de shaders, de systèmes de moteur, de modules middleware, de charges de travail asynchrones et de techniques de rendu personnalisées.

Une erreur d'instruction peut n'apparaître que dans un matériau, une passe d'éclairage ou un effet de post-traitement. Un défaut de synchronisation peut rester caché jusqu'à ce qu'une scène donnée mette suffisamment de travail en cours.

Le résultat peut aller d'une texture manquante à une géométrie scintillante, une réinitialisation du pilote, une mémoire corrompue ou un plantage complet. Aucun de ces résultats ne contredirait une couverture du décodeur de 100 %.

La politique stricte d'erreurs d'AnyPS5 peut donner l'impression que la compatibilité initiale est moins bonne tout en améliorant la valeur diagnostique. Sa documentation indique que les états non pris en charge ou inattendus déclenchent une erreur d'exécution et mettent fin au processus.

Cette approche évite de prétendre qu'un chemin non implémenté fonctionne. Elle donne également aux contributeurs un point d'échec plus clair qu'un jeu qui continue avec un état interne endommagé.

La même prudence s'applique au chiffre de 84,76 % des bibliothèques système rapporté avec l'étape GPU. L'implémentation de milliers de fonctions déclarées représente un travail considérable, mais la couverture numérique dit peu sur les fonctions manquantes qui bloquent un jeu particulier.

Une fonction obscure peut empêcher le démarrage. À l'inverse, un titre simple peut n'utiliser qu'un sous-ensemble restreint de l'interface disponible et fonctionner malgré d'importantes lacunes ailleurs.

La compatibilité progresse donc de manière inégale. Un projet peut atteindre un pourcentage global élevé tout en rencontrant des difficultés avec un jeu populaire, puis obtenir des progrès visibles grâce à un service soigneusement implémenté.

L’interprétation correcte de la couverture des shaders d’AnyPS5 est limitée, mais importante. Le vocabulaire d’instructions suivi par le décodeur est complet, ce qui permet aux contributeurs d’examiner des problèmes plus profonds de traduction et d’exécution sans cette catégorie particulière d’instructions inconnues.

Cette métrique ne doit pas être étendue à des affirmations sur un rendu universel, une prise en charge GPU achevée ou une compatibilité prochaine avec le catalogue PS5.

Le portage natif et l’émulation PS5 se heurtent à des goulets d’étranglement différents

AnyPS5 et les émulateurs PS5 conventionnels partagent de nombreux problèmes techniques, mais leurs architectures font apparaître ces problèmes à des étapes différentes.

Un émulateur présente généralement au logiciel un environnement conçu pour ressembler à la console d’origine. Il coordonne le matériel virtualisé, les services système, le comportement de la mémoire, la traduction graphique et les entrées derrière une frontière d’émulation.

AnyPS5 convertit au contraire l’exécutable et le relie à des implémentations compatibles avec l’hôte. Cette approche peut réduire certaines couches lorsque l’invité et l’hôte partagent une architecture CPU, mais elle n’élimine pas la nécessité de reproduire le comportement de la console.

La voie native avance une hypothèse convaincante en matière de performances. Si le code x86-64 d’origine peut être exécuté directement, l’hôte évite la lourde traduction CPU associée aux consoles utilisant des jeux d’instructions différents.

Cet avantage ne produit pas automatiquement de hautes performances. La traduction graphique, le traitement des appels système, la synchronisation et les correctifs de compatibilité consomment toujours des ressources. Le travail de correction peut également imposer des chemins prudents qui réduisent la vitesse.

L’émulation traditionnelle peut offrir une meilleure isolation et un contrôle centralisé. Un émulateur peut intercepter les comportements au sein d’un environnement d’exécution géré, ce qui peut simplifier la journalisation, la gestion de l’état et l’abstraction de plateforme.

Un processus natif converti obtient un accès direct à l’exécution de l’hôte, mais doit coexister avec le modèle applicatif du système d’exploitation hôte. Les différences de formats exécutables, de conventions d’appel, de comportement des exceptions et d’édition de liens dynamique deviennent des préoccupations d’ingénierie immédiates.

SharpEmu offre une comparaison utile, car il suit la voie de l’émulateur tout en tirant parti du CPU x86-64 de la PS5. En septembre 2026, ses développeurs ont indiqué que 12 des 55 titres testés atteignaient le jeu et que six fonctionnaient à 60 images par seconde.

Ces six titres n’avaient pas tous été testés du début à la fin. L’étiquette « jouable » autorisait encore de légers problèmes graphiques ou audio, selon les informations du projet citées dans une mise à jour de compatibilité.

Kyty a poursuivi une autre implémentation d’émulateur et produit des résultats visibles avec des logiciels plus exigeants. Pourtant, les démonstrations publiques, les chiffres de fréquence d’images et les courtes séquences de jeu n’établissent pas une compatibilité complète.

Ces projets illustrent pourquoi les preuves au niveau des titres comptent davantage qu’un pourcentage unique portant sur un sous-système. Une liste de compatibilité consigne le comportement de toute la pile dans des charges de travail réelles.

AnyPS5 met actuellement en avant Dreaming Sarah comme jeu vérifié. La documentation du projet indique que ce jeu de plateforme 2D fonctionne à 60 images par seconde stables sur une GeForce GTX 1050 Ti et un Intel Core i5-7500.

C’est une preuve significative que son architecture peut faire passer au moins un jeu par la conversion, l’édition de liens, la traduction graphique, les entrées et l’exécution. Ce n’est pas la preuve que la même voie s’étend directement à une sortie complexe d’un studio interne.

Certaines expérimentations de la communauté ont également signalé des conversions natives d’autres titres, dont Dead Cells. Ces démonstrations peuvent révéler des voies fonctionnelles, mais chacune doit être évaluée avec soin en fonction des correctifs nécessaires, des fonctionnalités manquantes et de la reproductibilité.

La comparaison la plus solide n’est donc pas un tableau de scores entre les projets. C’est une comparaison entre les méthodes de découverte et de résolution des défaillances de compatibilité.

Les émulateurs peuvent démontrer une compatibilité de jeu plus large tout en conservant une frontière d’exécution. AnyPS5 peut tester si la conversion statique et l’exécution native sur l’hôte offrent une voie à long terme plus propre pour les charges de travail compatibles.

Les deux approches se heurtent toujours à la même norme impitoyable. Un joueur se soucie de savoir si un jeu démarre, s’affiche correctement, accepte les entrées, sauvegarde la progression, maintient ses performances et tient du début à la fin.

Aucune étiquette architecturale ne remplace ces résultats.

Ce que 100 % de couverture ne garantit toujours pas

AnyPS5 a achevé une couche mesurable, mais les incertitudes restantes se situent précisément là où les vrais jeux deviennent difficiles à prendre en charge.

La première incertitude concerne la sémantique des shaders. La couverture publique indique que le décodeur reconnaît chaque instruction suivie, mais elle ne précise pas combien disposent de traductions SPIR-V complètes.

Elle ne révèle pas non plus combien de traductions ont été comparées au matériel PS5 sur des entrées représentatives. Les tests matériels comptent lorsque la documentation publique laisse un comportement ambigu.

La deuxième incertitude concerne les combinaisons. Une instruction individuelle peut réussir un test ciblé tandis qu’un shader plus long révèle des interactions impliquant le flux de contrôle, la précision, l’accès mémoire ou les opérations de sous-groupes.

Les programmes de shader s’appuient aussi sur des ressources fournies par le pipeline graphique. Une arithmétique correcte ne peut compenser une image, un tampon, un échantillonneur ou une cible de rendu décrits incorrectement.

La troisième incertitude concerne l’univers suivi lui-même. Le chiffre de 1 166 représente la liste d’instructions maintenue par AnyPS5. De futurs tests peuvent révéler des variantes, des encodages ou des comportements non documentés que le suivi actuel ne capture pas.

Cette possibilité n’invalide pas le pourcentage. Elle signifie que le pourcentage décrit un périmètre d’ingénierie versionné plutôt qu’une spécification immuable de chaque comportement du GPU de la PS5.

Les bibliothèques système constituent une cible mouvante similaire. Le projet comptait 3 038 fonctions déclarées dans l’instantané du 9 octobre, dont 2 575 étaient marquées comme implémentées.

D’autres fonctions peuvent entrer dans la base de données lorsqu’un autre jeu importe des interfaces jusque-là inconnues. Un dénominateur en croissance peut faire baisser le pourcentage affiché alors même que la base de code s’améliore.

Les décomptes de fonctions dissimulent également la profondeur. Un simple adaptateur et un service complexe à état occupent chacun une ligne, bien que leurs coûts d’implémentation diffèrent considérablement.

Une lecture multimédia, une mise en réseau, des services de compte, un comportement de stockage et une soumission graphique corrects peuvent exiger un état persistant et une gestion précise des erreurs. Ils ne peuvent pas toujours être réduits à une valeur de retour.

La quatrième incertitude concerne l’accès juridique et pratique. AnyPS5 indique ne pas distribuer de jeux protégés par le droit d’auteur, de firmware, de clés cryptographiques ni de bibliothèques propriétaires.

Sa documentation attribue aux utilisateurs la responsabilité d’obtenir les binaires légalement et de respecter les conditions de licence pertinentes. Cette limite est essentielle aux projets de préservation et d’interopérabilité opérant autour de logiciels commerciaux.

L’outil n’est pas une boutique alternative pour les jeux PS5. Les utilisateurs doivent toujours disposer d’un accès légitime aux logiciels qu’ils testent, ainsi que suivre tout processus technique nécessaire pour obtenir des fichiers compatibles.

La cinquième incertitude concerne la maintenance. Les jeux, les pilotes et les systèmes d’exploitation hôtes créent une vaste matrice de tests. Une conversion qui fonctionne sur un GPU peut révéler un problème différent ailleurs.

AnyPS5 utilise Vulkan pour cibler plusieurs systèmes, mais Windows et Linux diffèrent toujours dans le chargement des exécutables, les bibliothèques, les pilotes, le comportement du système de fichiers et les outils de débogage.

L’historique des versions du projet montre déjà du travail sur les shaders, le réseau, la lecture multimédia, les bibliothèques, la validation de compilation et la réédition de liens. Cette ampleur démontre à quel point le problème dépasse le simple décodage GPU.

Elle montre également pourquoi une activité rapide de commits ne doit pas être confondue avec une compatibilité achevée. Un jeune projet peut évoluer rapidement tout en restant expérimental et inadapté aux joueurs ordinaires.

Les utilisateurs doivent aussi résister à l’extrapolation depuis des titres légers vers de futurs blockbusters. Un petit jeu 2D peut valider l’architecture sans solliciter les chemins de rendu et système les plus exigeants.

Les grands jeux amplifient chaque point faible. Ils utilisent davantage de modules, plus de fonctionnalités graphiques, des ensembles de ressources plus vastes, un timing plus serré et des hypothèses propres aux moteurs, construites au fil d’années d’optimisation pour console.

Un résumé techniquement exact doit donc préserver les deux aspects de cette étape. AnyPS5 a supprimé chaque inconnue actuellement suivie de son décodeur de shaders, ce qui constitue un précieux travail de fond.

Il n’a pas établi une traduction complète des shaders, une équivalence GPU totale, une large compatibilité des bibliothèques système ni une prise en charge fiable du catalogue PS5.

Trois signaux montreront si AnyPS5 comble l’écart

Les prochaines preuves significatives viendront de tests sémantiques, d’une compatibilité de jeux reproductible et d’un dénominateur de bibliothèques système qui résiste à des charges de travail plus larges.

Le premier signal est un comportement d’instruction vérifié. Les contributeurs ont besoin de tests montrant que les opérations décodées se traduisent en SPIR-V correct et correspondent à la sortie matérielle attendue.

Les règles de contribution du projet vont déjà dans ce sens. Les modifications de shaders doivent citer une source technique précise ou des mesures effectuées sur du matériel réel, tandis que les cas non résolus restent explicitement considérés comme de la dette technique.

Une collection plus vaste de tests sémantiques automatisés renforcerait le chiffre de 100 %. Elle transformerait le suivi d’une carte de reconnaissance en éléments de preuve sur le comportement traduit.

Les rapports les plus utiles distingueraient au moins trois états : décodé, traduit et vérifié sur matériel. Cette ventilation permettrait aux observateurs de voir si la profondeur d’implémentation rattrape l’ampleur de la couverture.

Si les décomptes traduits et vérifiés augmentent rapidement, cette étape apparaîtra comme le début d’une phase ciblée de correction. Si la reconnaissance reste la seule couche complète, l’écart derrière le titre persistera.

Le deuxième signal est une liste de compatibilité reproductible. Davantage de jeux doivent fonctionner via des builds publics, avec du matériel, des systèmes d’exploitation, des réglages, des défauts connus et une profondeur de test documentés.

Le démarrage d’un titre doit rester distinct de l’accès aux menus, de l’entrée en jeu, de l’exécution à une fréquence d’images cible et de la finalisation du jeu. Combiner ces états masquerait davantage d’informations qu’il n’en révélerait.

Une entrée utile devrait également identifier les correctifs externes ou les étapes manuelles. La conversion native devient bien plus convaincante lorsqu’un autre utilisateur peut reproduire le résultat sans code privé ni modifications non documentées.

Le passage d’un jeu léger vérifié à plusieurs titres indépendants montrerait que l’architecture se généralise. La prise en charge d’un titre 3D exigeant fournirait un test de résistance bien plus solide.

Le troisième signal est la relation entre les fonctions système découvertes et implémentées. Les 84,76 % rapportés semblent encourageants, mais leur valeur dépend de la stabilité du dénominateur.

Si les tests de davantage de jeux révèlent de nombreuses fonctions supplémentaires, le pourcentage brut peut baisser. Cela représenterait une meilleure connaissance de la plateforme plutôt qu’une régression.

Ce qui compte est de savoir si les fonctions nouvellement découvertes reçoivent des implémentations précises et débloquent de vrais logiciels. Les résultats au niveau des titres devraient s’améliorer à mesure que la carte des interfaces s’étend.

Les observateurs devraient également surveiller si les échecs se déplacent plus profondément dans l’exécution. Le passage d’un jeu des erreurs de démarrage aux menus, au jeu et à des sessions plus longues peut montrer des progrès significatifs avant même qu’il ne soit qualifié de jouable.

La couverture des shaders d’AnyPS5 mérite l’attention, car elle élimine une vaste catégorie de défaillance immédiate. Chaque instruction suivie peut désormais entrer dans le décodeur au lieu de s’arrêter comme entrée inconnue.

La phase la plus difficile commence après cette reconnaissance. Les développeurs doivent montrer que les shaders traduits se comportent correctement, que les bibliothèques de remplacement reproduisent les services attendus et que les jeux convertis restent stables sous des charges de travail complètes.

Pour les développeurs, les chercheurs en préservation et les joueurs techniquement curieux, la meilleure question n’est plus de savoir si le suivi peut atteindre 100 %. Il y est déjà parvenu.

La question est de savoir quel pourcentage de ces 1 166 instructions peut résister à des tests sémantiques dans de vrais jeux, sur différents PC et sans correctifs cachés. Surveillez la liste de compatibilité vérifiée et les tests de shaders étayés par le matériel. Ces résultats détermineront si l’étape franchie par AnyPS5 devient une base pour faire tourner nativement des jeux PS5 sur PC ou reste une statistique de décodage impressionnante.