La copertura degli shader di AnyPS5 raggiunge il 100%, ma i giochi PS5 nativi su PC restano lontani
La copertura degli shader di AnyPS5 ha raggiunto il 100% sulle 1.166 istruzioni GPU monitorate, offrendo al progetto open source un importante traguardo tecnico con un limite significativo. Ogni istruzione elencata può ora essere riconosciuta, ma il riconoscimento non garantisce una traduzione corretta né un rendering affidabile dei giochi.
Questa distinzione separa un prezioso risultato ingegneristico dall'affermazione più eclatante secondo cui i giochi PlayStation 5 sarebbero pronti a funzionare nativamente sui normali PC. AnyPS5 deve ancora affrontare semantiche degli shader incompiute, librerie di sistema incomplete, problemi di sincronizzazione e comportamenti specifici dei singoli titoli.
Il progetto segue inoltre una strada diversa rispetto agli emulatori sperimentali come SharpEmu e Kyty. Anziché mantenere un ambiente di console virtuale, AnyPS5 converte gli eseguibili per Windows o Linux e fornisce librerie di sistema sostitutive. I suoi progressi mettono quindi alla prova un'idea più ampia: se il software PS5 possa essere adattato più come un carico di lavoro per un livello di compatibilità che come una console emulata in modo tradizionale.
La copertura degli shader di AnyPS5 ora include 1.166 istruzioni
Il nuovo traguardo colma una lacuna nel decoder degli shader di AnyPS5, non ogni ostacolo tra un eseguibile PS5 e un gioco PC funzionante.
Un'istantanea dei progressi datata 9 ottobre 2026 elenca 1.166 istruzioni GPU implementate su 1.166 monitorate. L'elenco si basa sui set di istruzioni AMD RDNA 1 e RDNA 2 e copre molteplici famiglie di istruzioni utilizzate nei programmi shader.
Queste famiglie includono operazioni scalari, operazioni vettoriali, accesso alla memoria, elaborazione delle immagini, condivisione dei dati e istruzioni di controllo del flusso. Insieme, costituiscono gran parte del vocabolario utilizzato dai programmi grafici di PlayStation 5 per dirigere la GPU AMD della console.
AnyPS5 usa una definizione specifica di “implementata” per questo monitoraggio. Un'istruzione si qualifica quando il decoder degli shader la riconosce. Il decoder è il componente che legge un'istruzione macchina e ne identifica l'operazione, gli operandi e la codifica.
Il riconoscimento conta perché un'istruzione sconosciuta può interrompere immediatamente il processo di traduzione. Lo strumento non può convertire uno shader se non riesce a determinare il significato di una parte del programma originale.
Tuttavia, riconoscere un'istruzione è diverso dal riprodurne il comportamento. Quest'ultimo richiede di tradurne la semantica in codice che produca gli stessi risultati tramite uno stack grafico per PC.
Secondo la documentazione pubblica del progetto, il suo ricompilatore di shader produce SPIR-V. SPIR-V è una rappresentazione intermedia che consente agli strumenti di esprimere programmi GPU per API tra cui Vulkan senza puntare direttamente al codice macchina di un singolo fornitore.
Il progetto afferma che l'output generato può essere controllato con SPIRV-Tools quando è abilitata un'opzione di convalida dedicata. Tale convalida può rilevare moduli malformati e violazioni strutturali. Non dimostra che ogni istruzione tradotta restituisca il risultato esatto previsto da un gioco PS5.
La differenza ricorda quella tra analizzare un dizionario tecnico completo e tradurre correttamente ogni possibile frase. Un traduttore deve prima riconoscere ogni parola, ma la sola copertura del vocabolario non risolve il contesto, le tempistiche o i comportamenti ambigui.
Il rapporto sulla copertura ha inoltre indicato l'implementazione delle librerie di sistema monitorate a 2.575 funzioni su 3.038 dichiarate, ovvero l'84,76%. Questa cifra comporta una propria precisazione.
Misura le funzioni già note e dichiarate dal progetto. Il denominatore può crescere quando gli sviluppatori scoprono ulteriori funzioni necessarie a un numero maggiore di giochi. Non è una percentuale fissa dell'interfaccia software privata completa di Sony.
Il dato sugli shader è più concreto entro l'ambito dichiarato. Ogni istruzione attualmente inclusa nell'elenco di monitoraggio RDNA del progetto raggiunge ora la soglia di riconoscimento. Questo offre ai contributori meno vicoli ciechi immediati quando esaminano shader sconosciuti.
Cambia anche il lavoro che resta da fare. Gli sviluppatori possono sempre più passare dal completamento delle voci mancanti del decoder al test della semantica, alla diagnosi dei fallimenti di rendering e al confronto dell'output con il comportamento previsto dell'hardware.
Questo rende il 100% un traguardo significativo. Semplicemente, non lo rende un verdetto di compatibilità.
Come funziona AnyPS5 senza un emulatore tradizionale
AnyPS5 scommette sul fatto che le familiari basi x86-64 e grafiche AMD della PS5 rendano la conversione più pratica della ricostruzione dell'intera console in software.
L'architettura del progetto parte da un vantaggio hardware. PlayStation 5 utilizza un processore AMD basato sul set di istruzioni x86-64, utilizzato anche dai PC Windows e Linux mainstream.
Le console più vecchie spesso si affidavano ad architetture CPU nettamente diverse dall'hardware desktop. Eseguire il loro software richiedeva una traduzione continua delle istruzioni o una simulazione dettagliata di processori non familiari.
AnyPS5 adotta un altro approccio. La sua panoramica del progetto descrive uno strumento per il porting automatico di eseguibili su Linux e Windows. Un relinker converte l'eseguibile originale in un formato nativo per il sistema operativo di destinazione.
Il relinking interviene sulla struttura e sulle dipendenze dell'eseguibile. Un programma PS5 si aspetta moduli, interfacce e comportamenti di caricamento specifici di Sony che non esistono in un'installazione PC standard.
AnyPS5 fornisce quindi sostituti per le librerie di sistema PRX della PS5. Le librerie PRX sono moduli eseguibili che espongono funzioni del sistema operativo e del runtime utilizzate dal software per console.
L'applicazione convertita si collega a queste implementazioni sostitutive. In linea di principio, il gioco può quindi operare come processo host nativo invece di essere eseguito all'interno di un processo di emulazione separato.
La grafica segue un percorso di conversione parallelo. Il ricompilatore degli shader decodifica le istruzioni GPU e genera SPIR-V per Vulkan, un'API grafica multipiattaforma supportata su Windows e Linux.
Questa architettura spiega perché il riconoscimento completo delle istruzioni sia importante. Qualsiasi shader che contenga una codifica sconosciuta crea una lacuna nella pipeline di conversione. Completare l'elenco monitorato consente al decoder di procedere più avanti prima di incontrare un'altra classe di errori.
Spiega anche perché il traguardo resti incompleto. Un decoder può identificare correttamente un'istruzione mentre al ricompilatore manca una traduzione SPIR-V completa del suo comportamento.
Anche una traduzione generata può essere sottilmente errata. Regole in virgola mobile, ordinamento della memoria, mascheramento delle lane, operazioni wave, campionamento delle texture e comportamento hardware non definito possono produrre difetti che appaiono solo in particolari carichi di lavoro.
I giochi per console dipendono inoltre da molto più che dal codice CPU e dagli shader. Si aspettano layout di memoria specifici, regole di sincronizzazione, comportamenti dei comandi grafici, servizi audio, interfacce di archiviazione, input del controller, tempistiche e risposte del sistema operativo.
Un eseguibile nativo può fallire perché manca una funzione prevista. Può anche fallire perché una funzione esistente restituisce un valore leggermente diverso, gestisce in modo errato un caso limite o completa il lavoro nell'ordine sbagliato.
Le regole di contributo del progetto riconoscono questa difficoltà. Le modifiche agli shader devono identificare se la loro semantica proviene dalla documentazione AMD, da Mesa, LLVM, misurazioni hardware o da un'altra fonte tecnica precisa.
La politica di contribuzione afferma che i revisori verificano la semantica degli shader rispetto all'hardware. I comportamenti che restano irrisolti devono generare un errore o entrare nel registro del debito tecnico del progetto.
Questa politica riflette una preferenza deliberata per un fallimento visibile rispetto a un'approssimazione silenziosa. Un arresto anomalo esplicito può rivelare il comportamento mancante. Uno stub silenzioso ma impreciso può corrompere lo stato e produrre risultati fuorvianti molto più tardi.
AnyPS5 non sta quindi semplicemente cambiando le estensioni dei file. Sta ricostruendo una quantità sufficiente dell'ambiente software PS5 affinché i programmi convertiti si comportino correttamente su un altro sistema operativo.
Il relinker, le librerie sostitutive e il ricompilatore degli shader formano un'unica catena. I progressi in qualsiasi singolo componente contano solo quando l'intera catena può supportare un titolo reale.
La vera sfida è tra copertura e correttezza
Il conflitto centrale non è tra AnyPS5 e Sony, né tantomeno tra porting ed emulazione. È tra la percentuale di copertura visibile del progetto e lo standard molto più difficile della correttezza comportamentale.
Un pannello di avanzamento comprime un lavoro complicato in numeri leggibili. Aiuta i contributori a individuare le aree mancanti e offre agli osservatori un modo per seguire un progetto in rapida evoluzione.
Il rischio inizia quando una metrica interna di ingegneria diventa un'affermazione pubblica sulla compatibilità. “Copertura al 100% delle istruzioni degli shader GPU” suona vicino a “supporto GPU completo”, anche se le due affermazioni descrivono soglie differenti.
La copertura risponde alla domanda se il decoder sappia che un'istruzione esiste. La correttezza chiede se lo shader tradotto completo si comporti come l'originale in ogni condizione rilevante.
Questa seconda domanda opera a più livelli. L'istruzione deve produrre i valori corretti, interagire correttamente con le istruzioni vicine e preservare le ipotesi del gioco sull'ordine di esecuzione.
Poi lo shader deve integrarsi con l'associazione delle risorse, le texture, i buffer, i render target e il flusso di comandi. Un'operazione autonoma corretta può comunque fallire all'interno di una pipeline grafica incompleta.
Infine, il risultato deve restare stabile tra GPU host e driver diversi. Vulkan riduce le differenze tra piattaforme attraverso un'API comune, ma non elimina ogni dettaglio di implementazione.
La convalida SPIR-V ricopre un ruolo similmente limitato. Un validatore può confermare che un modulo segua regole strutturali formali. Non può stabilire se il programma rappresenti lo shader PS5 previsto.
Una frase grammaticalmente valida può comunque affermare un fatto sbagliato. Allo stesso modo, un modulo SPIR-V valido può compilare ed essere eseguito producendo un'immagine errata.
Questa distinzione diventa particolarmente importante per gli esigenti giochi commerciali. I titoli moderni utilizzano grandi combinazioni di shader, sistemi del motore, moduli middleware, carichi di lavoro asincroni e tecniche di rendering personalizzate.
Un errore in un'istruzione potrebbe comparire soltanto in un materiale, in un passaggio di illuminazione o in un effetto di post-processing. Un difetto di sincronizzazione potrebbe restare nascosto finché una scena specifica non mette in esecuzione abbastanza lavoro simultaneo.
Il risultato può variare da una texture mancante a geometrie tremolanti, un reset del driver, memoria corrotta o un arresto anomalo completo. Nessuno di questi esiti contraddirebbe una copertura del decoder al 100%.
La rigorosa politica sugli errori di AnyPS5 può far apparire la compatibilità iniziale peggiore, migliorando al contempo il valore diagnostico. La documentazione afferma che gli stati non supportati o inattesi generano un errore di runtime e terminano il processo.
Questo approccio evita di fingere che un percorso non implementato funzioni. Offre inoltre ai contributori un punto di errore più chiaro rispetto a un gioco che prosegue con uno stato interno danneggiato.
La stessa cautela si applica alla cifra dell'84,76% relativa alle librerie di sistema, riportata accanto al traguardo GPU. L'implementazione di migliaia di funzioni dichiarate rappresenta un lavoro sostanziale, ma la copertura numerica dice poco su quali funzioni mancanti blocchino un gioco specifico.
Una funzione poco conosciuta può impedire l'avvio. Al contrario, un titolo semplice può usare solo un sottoinsieme ristretto dell'interfaccia disponibile e funzionare nonostante ampie lacune altrove.
La compatibilità avanza quindi in modo disomogeneo. Un progetto può raggiungere un'alta percentuale aggregata pur avendo difficoltà con un gioco popolare, per poi ottenere progressi visibili grazie a un singolo servizio implementato con cura.
La corretta interpretazione della copertura shader di AnyPS5 è circoscritta ma significativa. Il vocabolario del decoder monitorato è completo, consentendo ai contributori di indagare problemi più profondi di traduzione e runtime senza quella specifica classe di istruzioni sconosciute.
La metrica non deve essere estesa fino a sostenere affermazioni sul rendering universale, sul supporto GPU completo o sulla compatibilità a breve termine con il catalogo PS5.
Il Porting Nativo e l'Emulazione PS5 Affrontano Colli di Bottiglia Diversi
AnyPS5 e gli emulatori PS5 convenzionali condividono molti problemi tecnici, ma le loro architetture espongono tali problemi in punti diversi.
Un emulatore presenta normalmente al software un ambiente progettato per assomigliare alla console originale. Coordina hardware virtualizzato, servizi di sistema, comportamento della memoria, traduzione grafica e input oltre un confine di emulazione.
AnyPS5 converte invece l'eseguibile e lo collega a implementazioni compatibili con l'host. Questo può ridurre i livelli quando guest e host condividono un'architettura CPU, ma non elimina la necessità di riprodurre il comportamento della console.
Il percorso nativo offre un'ipotesi prestazionale convincente. Se il codice x86-64 originale può essere eseguito direttamente, l'host evita la pesante traduzione CPU associata alle console che usano set di istruzioni diversi.
Questo vantaggio non produce automaticamente prestazioni elevate. La traduzione grafica, la gestione delle chiamate di sistema, la sincronizzazione e le correzioni di compatibilità consumano comunque risorse. Il lavoro sulla correttezza può anche richiedere percorsi conservativi che riducono la velocità.
L'emulazione tradizionale può offrire migliore isolamento e controllo centralizzato. Un emulatore può intercettare il comportamento all'interno di un runtime gestito, semplificando potenzialmente logging, gestione dello stato e astrazione della piattaforma.
Un processo nativo convertito ottiene accesso diretto all'esecuzione dell'host, ma deve coesistere con il modello applicativo del sistema operativo ospite. Le differenze nei formati degli eseguibili, nelle convenzioni di chiamata, nel comportamento delle eccezioni e nel linking dinamico diventano problemi ingegneristici immediati.
SharpEmu offre un confronto utile perché segue la strada dell'emulatore pur beneficiando della CPU x86-64 della PS5. Nel settembre 2026, i suoi sviluppatori hanno riferito che 12 dei 55 titoli testati raggiungevano il gameplay e sei giravano a 60 fotogrammi al secondo.
Quei sei titoli non erano stati tutti testati dall'inizio alla fine. L'etichetta “giocabile” consentiva comunque piccoli problemi grafici o audio, secondo le informazioni del progetto citate in un aggiornamento sulla compatibilità.
Kyty ha perseguito un'altra implementazione di emulatore e ha prodotto risultati visibili con software più impegnativo. Tuttavia, dimostrazioni pubbliche, dati sul frame rate e brevi sequenze di gameplay non dimostrano una compatibilità completa.
Questi progetti illustrano perché le prove a livello di singolo titolo contano più di una percentuale relativa a un solo sottosistema. Un elenco di compatibilità registra il comportamento dell'intero stack sotto carichi di lavoro reali.
AnyPS5 indica attualmente Dreaming Sarah come gioco verificato. La documentazione del progetto afferma che il platform 2D gira stabilmente a 60 fotogrammi al secondo su una GeForce GTX 1050 Ti e un Intel Core i5-7500.
È una prova significativa del fatto che la sua architettura possa portare almeno un gioco attraverso conversione, linking, traduzione grafica, input ed esecuzione. Non è una prova che lo stesso percorso si adatti direttamente a un complesso titolo first-party.
Alcuni esperimenti della community hanno inoltre segnalato conversioni native di altri titoli, tra cui Dead Cells. Tali dimostrazioni possono rivelare percorsi funzionanti, ma ciascuna richiede un'attenta valutazione di patch necessarie, funzionalità mancanti e riproducibilità.
Il confronto più solido non è quindi una classifica tra progetti. È un confronto tra metodi per scoprire e risolvere i fallimenti di compatibilità.
Gli emulatori possono dimostrare una compatibilità di gameplay più ampia mantenendo un confine di runtime. AnyPS5 può verificare se la conversione statica e l'esecuzione nativa sull'host offrano un percorso a lungo termine più pulito per i carichi di lavoro compatibili.
Entrambe le strade affrontano comunque lo stesso standard inflessibile. A un giocatore interessa che un gioco si avvii, esegua correttamente il rendering, accetti l'input, salvi i progressi, mantenga le prestazioni e arrivi dall'inizio alla fine.
Nessuna etichetta architetturale può sostituire questi risultati.
Cosa Non Garantisce Ancora una Copertura del 100%
AnyPS5 ha completato uno strato misurabile, ma le sue incertezze residue si collocano proprio dove il supporto ai giochi reali diventa difficile.
La prima incertezza riguarda la semantica degli shader. La copertura pubblica indica che il decoder riconosce ogni istruzione monitorata, ma non specifica quante dispongano di traduzioni SPIR-V complete.
Non rivela neppure quante traduzioni siano state confrontate con l'hardware PS5 su input rappresentativi. I test hardware sono importanti quando la documentazione pubblica lascia ambiguo il comportamento.
La seconda incertezza riguarda le combinazioni. Una singola istruzione può superare un test mirato mentre uno shader più lungo espone interazioni che coinvolgono flusso di controllo, precisione, accesso alla memoria o operazioni di sottogruppo.
I programmi shader dipendono anche dalle risorse fornite dalla pipeline grafica. Un'aritmetica corretta non può compensare un'immagine, un buffer, un sampler o un render target descritti in modo errato.
La terza incertezza riguarda l'universo monitorato stesso. La cifra di 1.166 rappresenta l'elenco di istruzioni mantenuto da AnyPS5. Test futuri possono rivelare varianti, codifiche o comportamenti non documentati che il tracker attuale non cattura.
Questa possibilità non invalida la percentuale. Significa che la percentuale descrive un ambito ingegneristico versionato anziché una specifica immutabile di ogni comportamento della GPU PS5.
Le librerie di sistema presentano un analogo obiettivo in movimento. Il progetto contava 3.038 funzioni dichiarate nello snapshot del 9 ottobre, di cui 2.575 contrassegnate come implementate.
Altre funzioni possono entrare nel database quando un nuovo gioco importa interfacce mai osservate prima. Un denominatore crescente può abbassare la percentuale visualizzata anche mentre la codebase migliora.
Anche il conteggio delle funzioni nasconde la profondità. Un semplice wrapper e un complesso servizio con stato occupano entrambi una riga, sebbene i loro costi di implementazione differiscano drasticamente.
La corretta riproduzione di riproduzione multimediale, networking, servizi account, comportamento dell'archiviazione e invio grafico può richiedere stato persistente e gestione accurata degli errori. Non sempre può essere ridotta a un valore di ritorno.
La quarta incertezza riguarda l'accesso legale e pratico. AnyPS5 afferma di non distribuire giochi protetti da copyright, firmware, chiavi crittografiche o librerie proprietarie.
La sua documentazione attribuisce agli utenti la responsabilità di ottenere legalmente i binari e rispettare i termini di licenza pertinenti. Questo confine è essenziale per i progetti di preservazione e interoperabilità che operano attorno al software commerciale.
Lo strumento non è un negozio alternativo di giochi PS5. Gli utenti devono comunque avere accesso legittimo al software che testano, insieme a qualsiasi processo tecnico necessario per ottenere file compatibili.
La quinta incertezza riguarda la manutenzione. Giochi, driver e sistemi operativi host creano un'ampia matrice di test. Una conversione che funziona su una GPU può esporre un problema diverso altrove.
AnyPS5 usa Vulkan per rivolgersi a più sistemi, ma Windows e Linux differiscono comunque nel caricamento degli eseguibili, nelle librerie, nei driver, nel comportamento del filesystem e negli strumenti di debugging.
La cronologia delle release del progetto mostra già lavoro su shader, networking, riproduzione multimediale, librerie, validazione delle build e relinking. Questa ampiezza dimostra quanto il problema si estenda oltre la decodifica GPU.
Mostra anche perché una rapida attività di commit non debba essere confusa con una compatibilità completata. Un progetto giovane può cambiare rapidamente pur rimanendo sperimentale e inadatto ai giocatori comuni.
Gli utenti dovrebbero inoltre evitare di estrapolare da titoli leggeri ai futuri blockbuster. Un piccolo gioco 2D può convalidare l'architettura senza esercitare i percorsi di rendering e sistema più impegnativi.
I giochi di grandi dimensioni amplificano ogni punto debole. Usano più moduli, più funzionalità grafiche, set di risorse più ampi, tempistiche più serrate e ipotesi specifiche del motore costruite attraverso anni di ottimizzazione per console.
Un riepilogo tecnicamente accurato deve quindi preservare entrambi gli aspetti del traguardo. AnyPS5 ha eliminato ogni elemento attualmente sconosciuto monitorato dal proprio decoder shader, un prezioso lavoro fondamentale.
Non ha dimostrato una traduzione shader completa, piena equivalenza GPU, ampia compatibilità delle librerie di sistema o supporto affidabile per il catalogo PS5.
Tre Segnali Mostreranno se AnyPS5 Sta Colmando il Divario
Le prossime prove significative arriveranno da test semantici, compatibilità dei giochi riproducibile e un denominatore delle librerie di sistema che resista a carichi di lavoro più ampi.
Il primo segnale è il comportamento verificato delle istruzioni. I contributori hanno bisogno di test che dimostrino che le operazioni decodificate si traducano in SPIR-V corretto e corrispondano all'output hardware atteso.
Le regole di contribuzione del progetto puntano già in questa direzione. Le modifiche agli shader devono citare una fonte tecnica precisa o misurazioni provenienti da hardware reale, mentre i casi irrisolti rimangono esplicitamente debito tecnico.
Una raccolta più ampia di test semantici automatizzati rafforzerebbe il dato del 100%. Trasformerebbe il tracker da una mappa di riconoscimento in una prova del comportamento tradotto.
La reportistica più utile separerebbe almeno tre stati: decodificato, tradotto e verificato su hardware. Questa ripartizione permetterebbe agli osservatori di vedere se la profondità dell'implementazione sta raggiungendo l'ampiezza.
Se i conteggi di elementi tradotti e verificati cresceranno rapidamente, il traguardo apparirà come l'inizio di una fase mirata alla correttezza. Se il riconoscimento resterà l'unico livello completo, il divario dietro il titolo persisterà.
Il secondo segnale è un elenco di compatibilità riproducibile. Più giochi devono funzionare tramite build pubbliche con hardware, sistemi operativi, impostazioni, difetti noti e profondità dei test documentati.
L'avvio di un titolo dovrebbe rimanere distinto dal raggiungere i menu, entrare nel gameplay, girare a un frame rate obiettivo e completare il gioco. Unire questi stati nasconderebbe più di quanto rivelerebbe.
Una voce utile dovrebbe inoltre identificare patch esterne o passaggi manuali. La conversione nativa diventa molto più convincente quando un altro utente può riprodurre il risultato senza codice privato o modifiche non documentate.
Il passaggio da un solo gioco leggero verificato a diversi titoli indipendenti dimostrerebbe che l'architettura si generalizza. Il supporto a un impegnativo titolo 3D fornirebbe uno stress test molto più solido.
Il terzo segnale è il rapporto tra funzioni di sistema scoperte e implementate. L'84,76% riportato sembra incoraggiante, ma il suo valore dipende dalla stabilità del denominatore.
Se i test su più giochi rivelassero molte funzioni aggiuntive, la percentuale grezza potrebbe diminuire. Ciò rappresenterebbe una migliore conoscenza della piattaforma anziché una regressione.
Ciò che conta è se le funzioni appena scoperte ricevano implementazioni accurate e sblocchino software reale. I risultati a livello di titolo dovrebbero migliorare man mano che la mappa delle interfacce si espande.
Gli osservatori dovrebbero inoltre verificare se i fallimenti si spostano più in profondità nell'esecuzione. Un gioco che passa dagli errori di avvio ai menu, al gameplay e a sessioni più lunghe può mostrare progressi significativi anche prima di essere qualificato come giocabile.
La copertura shader di AnyPS5 merita attenzione perché elimina un'ampia classe di fallimento immediato. Ogni istruzione monitorata può ora entrare nel decoder anziché fermarsi come input sconosciuto.
La fase più difficile inizia dopo quel riconoscimento. Gli sviluppatori devono dimostrare che gli shader tradotti si comportano correttamente, che le librerie sostitutive riproducono i servizi attesi e che i giochi convertiti rimangono stabili sotto carichi di lavoro completi.
Per sviluppatori, ricercatori della preservazione e giocatori tecnicamente curiosi, la domanda migliore non è più se il tracker possa raggiungere il 100%. Lo ha già fatto.
La domanda è quale percentuale di quelle 1.166 istruzioni possa superare i test semantici all’interno di giochi reali, su PC diversi, senza patch nascoste. Osservate l’elenco di compatibilità verificata e i test degli shader supportati dall’hardware. Quei risultati determineranno se il traguardo di AnyPS5 diventerà una base per giochi PS5 nativi su PC oppure rimarrà un’impressionante statistica del decoder.
