Pokrycie shaderów AnyPS5 osiąga 100%, ale natywne gry PS5 na PC wciąż są odległą perspektywą

Pokrycie shaderów AnyPS5 osiągnęło 100% dla 1166 śledzonych instrukcji GPU, co stanowi ważny kamień milowy dla projektu open source, choć z istotnym zastrzeżeniem. Każda wymieniona instrukcja może być teraz rozpoznana, jednak rozpoznanie nie gwarantuje poprawnego tłumaczenia ani niezawodnego renderowania gier.

To rozróżnienie oddziela wartościowe osiągnięcie inżynieryjne od bardziej spektakularnego twierdzenia, że gry na PlayStation 5 są gotowe do natywnego uruchamiania na zwykłych komputerach PC. AnyPS5 nadal musi uporać się z niedokończoną semantyką shaderów, niekompletnymi bibliotekami systemowymi, problemami z synchronizacją oraz zachowaniem charakterystycznym dla konkretnych tytułów.

Projekt obiera też inną drogę niż eksperymentalne emulatory, takie jak SharpEmu i Kyty. Zamiast utrzymywać wirtualne środowisko konsoli, AnyPS5 konwertuje pliki wykonywalne dla Windows lub Linux i dostarcza zastępcze biblioteki systemowe. Jego postępy sprawdzają zatem szerszą koncepcję: czy oprogramowanie PS5 można dostosować bardziej jak obciążenie warstwy kompatybilności niż jak konsolę emulowaną tradycyjnymi metodami.

Pokrycie shaderów AnyPS5 obejmuje teraz 1166 instrukcji

Nowy kamień milowy eliminuje lukę w dekoderze shaderów AnyPS5, a nie każdą przeszkodę między plikiem wykonywalnym PS5 a działającą grą na PC.

Zestawienie postępów z 9 października 2026 r. wskazuje, że zaimplementowano 1166 z 1166 śledzonych instrukcji GPU. Lista opiera się na zestawach instrukcji AMD RDNA 1 i RDNA 2 oraz obejmuje wiele rodzin instrukcji używanych w programach shaderów.

Rodziny te obejmują operacje skalarne, operacje wektorowe, dostęp do pamięci, przetwarzanie obrazów, współdzielenie danych oraz instrukcje sterowania przepływem. Razem tworzą znaczną część słownika, którym posługują się programy graficzne PlayStation 5 podczas sterowania układem GPU konsoli opartym na technologii AMD.

AnyPS5 stosuje w tym zestawieniu konkretną definicję słowa „zaimplementowana”. Instrukcja kwalifikuje się, gdy dekoder shaderów ją rozpoznaje. Dekoder to komponent, który odczytuje instrukcję maszynową i identyfikuje jej działanie, operandy oraz kodowanie.

Rozpoznawanie ma znaczenie, ponieważ nieznana instrukcja może natychmiast zatrzymać proces tłumaczenia. Narzędzie nie może przekonwertować shadera, jeśli nie potrafi określić znaczenia fragmentu oryginalnego programu.

Rozpoznanie instrukcji różni się jednak od odtworzenia jej zachowania. To drugie wymaga przełożenia jej semantyki na kod, który daje takie same wyniki w stosie graficznym komputera PC.

Według publicznej dokumentacji projektu jego rekompilator shaderów generuje SPIR-V. SPIR-V jest pośrednią reprezentacją, która pozwala narzędziom wyrażać programy GPU dla interfejsów API, w tym Vulkan, bez bezpośredniego kierowania ich na kod maszynowy konkretnego producenta.

Projekt podaje, że wygenerowane dane wyjściowe można sprawdzać za pomocą SPIRV-Tools po włączeniu dedykowanej opcji walidacji. Taka walidacja może wykrywać nieprawidłowo sformowane moduły i naruszenia strukturalne. Nie dowodzi jednak, że każda przetłumaczona instrukcja zwraca dokładnie taki wynik, jakiego oczekuje gra PS5.

Różnica przypomina posiadanie kompletnego słownika technicznego w porównaniu z poprawnym tłumaczeniem każdego możliwego zdania. Tłumacz musi najpierw rozpoznać każde słowo, ale samo pokrycie słownictwa nie rozwiązuje kwestii kontekstu, czasu ani niejednoznacznego zachowania.

Raport pokrycia wskazuje również, że implementacja śledzonych bibliotek systemowych obejmuje 2575 z 3038 zadeklarowanych funkcji, czyli 84,76%. Ta liczba także wymaga zastrzeżenia.

Mierzy funkcje już znane i zadeklarowane przez projekt. Mianownik może rosnąć, gdy deweloperzy odkrywają kolejne funkcje potrzebne większej liczbie gier. Nie jest to stały odsetek kompletnego prywatnego interfejsu oprogramowania Sony.

Liczba dotycząca shaderów jest bardziej konkretna w ramach wskazanego zakresu. Każda instrukcja obecnie uwzględniona na liście śledzenia RDNA projektu osiąga teraz próg rozpoznawania. Daje to współtwórcom mniej natychmiastowych ślepych uliczek podczas analizowania nieznanych shaderów.

Zmienia to również charakter dalszych prac. Deweloperzy mogą coraz częściej przechodzić od uzupełniania brakujących wpisów dekodera do testowania semantyki, diagnozowania błędów renderowania oraz porównywania wyników z oczekiwanym zachowaniem sprzętu.

Ta zmiana sprawia, że 100% jest znaczącym kamieniem milowym. Nie czyni jednak z niego werdyktu w sprawie kompatybilności.

Jak AnyPS5 działa bez tradycyjnego emulatora

AnyPS5 zakłada, że znane fundamenty PS5 — x86-64 i grafika AMD — czynią konwersję bardziej praktyczną niż odtwarzanie całej konsoli w oprogramowaniu.

Architektura projektu zaczyna się od przewagi sprzętowej. PlayStation 5 korzysta z procesora AMD opartego na zestawie instrukcji x86-64, używanym również przez popularne komputery PC z Windows i Linux.

Starsze konsole często wykorzystywały architektury CPU znacznie różniące się od sprzętu desktopowego. Uruchamianie ich oprogramowania wymagało ciągłego tłumaczenia instrukcji lub szczegółowej symulacji nieznanych procesorów.

AnyPS5 wybiera inne podejście. Jego opis projektu przedstawia narzędzie do automatycznego portowania plików wykonywalnych na Linux i Windows. Relinker konwertuje oryginalny plik wykonywalny do natywnego formatu docelowego systemu operacyjnego.

Relinkowanie zajmuje się strukturą i zależnościami pliku wykonywalnego. Program PS5 oczekuje charakterystycznych dla Sony modułów, interfejsów i zachowań ładowania, których nie ma w standardowej instalacji PC.

Dlatego AnyPS5 zapewnia zamienniki systemowych bibliotek PRX PS5. Biblioteki PRX to moduły wykonywalne udostępniające funkcje systemu operacyjnego i środowiska uruchomieniowego wykorzystywane przez oprogramowanie konsoli.

Skonwertowana aplikacja łączy się z tymi zastępczymi implementacjami. Teoretycznie gra może wtedy działać jako natywny proces hosta, zamiast pracować w oddzielnym procesie emulacji.

Grafika podąża równoległą ścieżką konwersji. Rekompilator shaderów dekoduje instrukcje GPU i generuje SPIR-V dla Vulkan, wieloplatformowego API graficznego obsługiwanego przez Windows i Linux.

Ta architektura wyjaśnia, dlaczego pełne rozpoznawanie instrukcji ma znaczenie. Każdy shader zawierający nieznane kodowanie tworzy lukę w potoku konwersji. Zamknięcie śledzonej listy pozwala dekoderowi przejść dalej, zanim napotka kolejną klasę błędu.

Wyjaśnia też, dlaczego kamień milowy pozostaje niepełny. Dekoder może poprawnie rozpoznać instrukcję, podczas gdy rekompilator nie ma jeszcze ukończonego tłumaczenia jej zachowania na SPIR-V.

Nawet wygenerowane tłumaczenie może być subtelnie błędne. Reguły zmiennoprzecinkowe, porządkowanie pamięci, maskowanie linii wykonawczych, operacje wave, próbkowanie tekstur i niezdefiniowane zachowanie sprzętu mogą powodować defekty widoczne tylko w określonych obciążeniach.

Gry konsolowe zależą też od czegoś więcej niż kod CPU i shadery. Oczekują konkretnych układów pamięci, zasad synchronizacji, zachowania poleceń graficznych, usług audio, interfejsów pamięci masowej, wejścia z kontrolera, czasu i odpowiedzi systemu operacyjnego.

Natywny plik wykonywalny może zakończyć działanie, ponieważ brakuje jednej oczekiwanej funkcji. Może też zawieść, ponieważ istniejąca funkcja zwraca nieco inną wartość, niepoprawnie obsługuje przypadek brzegowy lub kończy pracę w niewłaściwej kolejności.

Zasady współtworzenia projektu uznają tę trudność. Zmiany dotyczące shaderów muszą wskazywać, czy ich semantyka pochodzi z dokumentacji AMD, Mesa, LLVM, pomiarów sprzętowych czy innego konkretnego źródła technicznego.

Polityka współtworzenia stwierdza, że recenzenci sprawdzają semantykę shaderów względem sprzętu. Zachowanie, które pozostaje nieustalone, musi zgłosić błąd albo trafić do rejestru długu technicznego projektu.

Ta polityka odzwierciedla świadomą preferencję dla widocznej awarii zamiast cichego przybliżenia. Jawne przerwanie działania może ujawnić brakujące zachowanie. Cichy, lecz niedokładny stub może uszkodzić stan i znacznie później wywołać mylące rezultaty.

AnyPS5 nie zmienia zatem po prostu rozszerzeń plików. Odtwarza wystarczającą część środowiska programowego PS5, aby skonwertowane programy zachowywały się poprawnie w innym systemie operacyjnym.

Relinker, zastępcze biblioteki i rekompilator shaderów tworzą jeden łańcuch. Postęp w pojedynczym komponencie ma znaczenie tylko wtedy, gdy cały łańcuch może obsłużyć rzeczywisty tytuł.

Rzeczywista rywalizacja to pokrycie kontra poprawność

Główny konflikt nie dotyczy AnyPS5 kontra Sony ani nawet portowania kontra emulacja. Chodzi o widoczny procent pokrycia projektu w zestawieniu ze znacznie trudniejszym standardem poprawności zachowania.

Panel postępów sprowadza skomplikowaną pracę do czytelnych liczb. Pomaga współtwórcom lokalizować brakujące obszary i daje obserwatorom sposób na śledzenie szybko rozwijającego się projektu.

Niebezpieczeństwo pojawia się, gdy wewnętrzna metryka inżynieryjna staje się publicznym twierdzeniem o kompatybilności. „100% pokrycia instrukcji shaderów GPU” brzmi podobnie do „pełnej obsługi GPU”, chociaż te stwierdzenia opisują różne progi.

Pokrycie odpowiada na pytanie, czy dekoder wie o istnieniu instrukcji. Poprawność pyta, czy kompletny przetłumaczony shader zachowuje się jak oryginał w każdych istotnych warunkach.

To drugie pytanie działa na kilku poziomach. Instrukcja musi generować właściwe wartości, poprawnie współdziałać z sąsiednimi instrukcjami i zachowywać założenia gry dotyczące kolejności wykonania.

Następnie shader musi integrować się z wiązaniem zasobów, teksturami, buforami, celami renderowania i strumieniem poleceń. Poprawna samodzielna operacja wciąż może zawieść w niekompletnym potoku graficznym.

Wreszcie wynik musi pozostawać stabilny na różnych GPU hosta i sterownikach. Vulkan ogranicza różnice między platformami za pomocą wspólnego API, lecz nie usuwa każdego szczegółu implementacyjnego.

Walidacja SPIR-V odgrywa podobnie ograniczoną rolę. Walidator może potwierdzić, że moduł przestrzega formalnych zasad strukturalnych. Nie potrafi określić, czy program reprezentuje zamierzony shader PS5.

Zdanie poprawne gramatycznie może nadal zawierać błędny fakt. Podobnie prawidłowy moduł SPIR-V może się kompilować i uruchamiać, a mimo to generować niepoprawny obraz.

To rozróżnienie staje się szczególnie ważne w wymagających grach komercyjnych. Współczesne tytuły wykorzystują rozbudowane kombinacje shaderów, systemów silnika, modułów middleware, asynchronicznych obciążeń i niestandardowych technik renderowania.

Błąd instrukcji może pojawić się tylko w jednym materiale, przebiegu oświetlenia albo efekcie postprocessingu. Defekt synchronizacji może pozostać ukryty, dopóki konkretna scena nie uruchomi wystarczająco dużej ilości pracy równolegle.

Skutkiem może być brakująca tekstura, migocząca geometria, reset sterownika, uszkodzona pamięć albo całkowita awaria. Żaden z tych rezultatów nie przeczyłby 100% pokryciu dekodera.

Surowa polityka błędów AnyPS5 może sprawiać, że wczesna kompatybilność wygląda gorzej, jednocześnie poprawiając wartość diagnostyczną. Dokumentacja projektu podaje, że nieobsługiwane lub nieoczekiwane stany zgłaszają błąd wykonawczy i kończą proces.

Takie podejście unika udawania, że niezaimplementowana ścieżka działa. Daje też współtwórcom wyraźniejszy punkt awarii niż gra, która kontynuuje działanie z uszkodzonym stanem wewnętrznym.

Ta sama ostrożność dotyczy wskaźnika 84,76% bibliotek systemowych, zgłoszonego obok kamienia milowego GPU. Implementacja tysięcy zadeklarowanych funkcji oznacza znaczną pracę, lecz pokrycie liczbowe niewiele mówi o tym, które brakujące funkcje blokują konkretną grę.

Jedna mało istotna z pozoru funkcja może uniemożliwić uruchomienie. Z kolei prosty tytuł może korzystać tylko z wąskiego podzbioru dostępnego interfejsu i działać mimo dużych luk w innych miejscach.

Kompatybilność rozwija się więc nierównomiernie. Projekt może osiągnąć wysoki łączny procent, a jednocześnie mieć trudności z popularną grą, po czym uzyskać widoczny postęp dzięki jednej starannie zaimplementowanej usłudze.

Właściwa interpretacja pokrycia shaderów AnyPS5 jest wąska, ale istotna. Śledzone słownictwo dekodera jest kompletne, dzięki czemu współtwórcy mogą badać głębsze problemy z translacją i działaniem w środowisku wykonawczym bez tej konkretnej klasy nieznanych instrukcji.

Nie należy rozciągać tej metryki na twierdzenia o uniwersalnym renderowaniu, ukończonej obsłudze GPU ani bliskiej kompatybilności z katalogiem PS5.

Natywne portowanie i emulacja PS5 napotykają różne wąskie gardła

AnyPS5 i konwencjonalne emulatory PS5 mierzą się z wieloma wspólnymi problemami technicznymi, lecz ich architektury ujawniają je na różnych etapach.

Emulator zwykle zapewnia oprogramowaniu środowisko zaprojektowane tak, by przypominało oryginalną konsolę. Koordynuje zwirtualizowany sprzęt, usługi systemowe, zachowanie pamięci, translację grafiki i wejście użytkownika za granicą emulacji.

AnyPS5 zamiast tego konwertuje plik wykonywalny i łączy go z implementacjami zgodnymi z hostem. Może to ograniczyć liczbę warstw, gdy środowisko gościa i hosta korzystają z tej samej architektury CPU, ale nie eliminuje potrzeby odtworzenia zachowania konsoli.

Podejście natywne oferuje przekonującą hipotezę wydajnościową. Jeśli oryginalny kod x86-64 może być wykonywany bezpośrednio, host unika kosztownej translacji CPU typowej dla konsol korzystających z innych zestawów instrukcji.

Ta przewaga nie przekłada się automatycznie na wysoką wydajność. Translacja grafiki, obsługa wywołań systemowych, synchronizacja i poprawki kompatybilności nadal zużywają zasoby. Prace nad poprawnością mogą też wymagać konserwatywnych ścieżek, które obniżają szybkość.

Tradycyjna emulacja może zapewniać lepszą izolację i scentralizowaną kontrolę. Emulator może przechwytywać zachowanie wewnątrz zarządzanego środowiska wykonawczego, co może upraszczać rejestrowanie, zarządzanie stanem i abstrakcję platformy.

Skonwertowany proces natywny zyskuje bezpośredni dostęp do wykonania na hoście, ale musi współistnieć z modelem aplikacji systemu operacyjnego hosta. Różnice w formatach plików wykonywalnych, konwencjach wywołań, zachowaniu wyjątków i dynamicznym linkowaniu stają się natychmiastowymi problemami inżynieryjnymi.

SharpEmu stanowi użyteczne porównanie, ponieważ podąża drogą emulatora, jednocześnie korzystając z procesora x86-64 PS5. We wrześniu 2026 roku jego twórcy poinformowali, że 12 z 55 testowanych tytułów osiągnęło etap rozgrywki, a sześć działało z szybkością 60 klatek na sekundę.

Nie wszystkie z tych sześciu tytułów zostały przetestowane od początku do końca. Zgodnie z informacjami projektu przytoczonymi w aktualizacji dotyczącej kompatybilności, oznaczenie „grywalne” nadal dopuszczało drobne problemy z grafiką lub dźwiękiem.

Kyty rozwija inną implementację emulatora i osiągnął widoczne rezultaty z bardziej wymagającym oprogramowaniem. Jednak publiczne demonstracje, dane o liczbie klatek na sekundę i krótkie sekwencje rozgrywki nie dowodzą pełnej kompatybilności.

Projekty te pokazują, dlaczego dowody na poziomie konkretnych tytułów są ważniejsze niż pojedynczy procent podsystemu. Lista kompatybilności rejestruje zachowanie całego stosu przy rzeczywistych obciążeniach.

AnyPS5 obecnie wskazuje Dreaming Sarah jako zweryfikowaną grę. Dokumentacja projektu podaje, że ta platformówka 2D działa stabilnie z szybkością 60 klatek na sekundę na GeForce GTX 1050 Ti i Intel Core i5-7500.

To istotny dowód, że architektura może przeprowadzić przynajmniej jedną grę przez konwersję, linkowanie, translację grafiki, obsługę wejścia i wykonanie. Nie jest to dowód, że ta sama ścieżka bezpośrednio skaluje się do złożonej produkcji first-party.

Niektóre eksperymenty społeczności również zgłaszały natywne konwersje innych tytułów, w tym Dead Cells. Takie demonstracje mogą ujawniać działające ścieżki, ale każda wymaga starannej oceny pod kątem wymaganych poprawek, brakujących funkcji i odtwarzalności.

Najtrafniejsze porównanie nie jest zatem tabelą wyników między projektami. Jest nim porównanie metod wykrywania i rozwiązywania błędów kompatybilności.

Emulatory mogą wykazywać szerszą kompatybilność w rozgrywce przy zachowaniu granicy środowiska wykonawczego. AnyPS5 może sprawdzić, czy statyczna konwersja i natywne wykonanie na hoście oferują czystszą długoterminową ścieżkę dla kompatybilnych obciążeń.

Obie drogi nadal mierzą się z tym samym bezlitosnym standardem. Gracza obchodzi, czy gra się uruchamia, renderuje poprawnie, przyjmuje dane wejściowe, zapisuje postępy, utrzymuje wydajność i działa od początku do końca.

Żadna etykieta architektoniczna nie zastąpi tych rezultatów.

Czego nadal nie gwarantuje 100% pokrycia

AnyPS5 ukończył jedną mierzalną warstwę, lecz pozostałe niepewności znajdują się dokładnie tam, gdzie obsługa rzeczywistych gier staje się trudna.

Pierwsza niepewność dotyczy semantyki shaderów. Publiczne pokrycie wskazuje, że dekoder rozpoznaje każdą śledzoną instrukcję, ale nie określa, ile z nich ma kompletne translacje do SPIR-V.

Nie ujawnia też, ile translacji porównano ze sprzętem PS5 dla reprezentatywnych danych wejściowych. Testowanie na sprzęcie ma znaczenie, gdy publiczna dokumentacja pozostawia zachowanie niejednoznacznym.

Druga niepewność dotyczy kombinacji. Pojedyncza instrukcja może przejść ukierunkowany test, podczas gdy dłuższy shader ujawni interakcje związane z przepływem sterowania, precyzją, dostępem do pamięci lub operacjami podgrup.

Programy shaderów polegają także na zasobach dostarczanych przez potok graficzny. Poprawna arytmetyka nie zrekompensuje nieprawidłowo opisanego obrazu, bufora, samplera ani celu renderowania.

Trzecia niepewność dotyczy samego śledzonego zakresu. Liczba 1 166 reprezentuje listę instrukcji utrzymywaną przez AnyPS5. Przyszłe testy mogą ujawnić nieudokumentowane warianty, kodowania lub zachowania, których obecny tracker nie obejmuje.

Taka możliwość nie unieważnia tego procentu. Oznacza, że procent opisuje wersjonowany zakres prac inżynieryjnych, a nie niezmienną specyfikację każdego zachowania GPU PS5.

Biblioteki systemowe stanowią podobnie zmienny cel. Projekt naliczył 3 038 zadeklarowanych funkcji w migawce z 9 października, z czego 2 575 oznaczono jako zaimplementowane.

Więcej funkcji może trafić do bazy danych, gdy kolejna gra importuje wcześniej niewidziane interfejsy. Rosnący mianownik może obniżyć wyświetlany procent, nawet gdy baza kodu się poprawia.

Liczba funkcji ukrywa też głębię implementacji. Prosty wrapper i złożona usługa stanowa zajmują po jednym wierszu, choć ich koszty implementacji różnią się drastycznie.

Poprawne odtwarzanie mediów, sieć, usługi kont, zachowanie pamięci masowej i przesyłanie zadań graficznych mogą wymagać trwałego stanu oraz precyzyjnej obsługi błędów. Nie zawsze można je sprowadzić do wartości zwracanej.

Czwarta niepewność dotyczy dostępu prawnego i praktycznego. AnyPS5 podaje, że nie dystrybuuje gier chronionych prawem autorskim, firmware'u, kluczy kryptograficznych ani własnościowych bibliotek.

Jego dokumentacja nakłada na użytkowników odpowiedzialność za legalne pozyskiwanie plików binarnych i przestrzeganie odpowiednich warunków licencyjnych. Ta granica jest kluczowa dla projektów zachowywania oprogramowania i interoperacyjności działających wokół komercyjnego oprogramowania.

Narzędzie nie jest alternatywnym sklepem z grami na PS5. Użytkownicy nadal potrzebują legalnego dostępu do testowanego oprogramowania, wraz z wszelkimi technicznymi procesami wymaganymi do uzyskania zgodnych plików.

Piąta niepewność dotyczy utrzymania. Gry, sterowniki i systemy operacyjne hosta tworzą dużą macierz testową. Konwersja działająca na jednym GPU może ujawnić inny problem gdzie indziej.

AnyPS5 używa Vulkan do obsługi wielu systemów, lecz Windows i Linux nadal różnią się ładowaniem plików wykonywalnych, bibliotekami, sterownikami, zachowaniem systemu plików i narzędziami do debugowania.

Historia wydań projektu pokazuje już prace nad shaderami, siecią, odtwarzaniem mediów, bibliotekami, walidacją kompilacji i ponownym linkowaniem. Ten szeroki zakres pokazuje, jak daleko problem wykracza poza dekodowanie GPU.

Pokazuje też, dlaczego szybkiej aktywności w commitach nie należy mylić z ukończoną kompatybilnością. Młody projekt może szybko się zmieniać, pozostając eksperymentalnym i nieodpowiednim dla zwykłych graczy.

Użytkownicy powinni też powstrzymać się od ekstrapolowania wyników z lekkich tytułów na przyszłe blockbustery. Niewielka gra 2D może zweryfikować architekturę, nie obciążając najbardziej wymagających ścieżek renderowania i systemowych.

Duże gry wzmacniają każdy słaby punkt. Korzystają z większej liczby modułów, większej liczby funkcji graficznych, większych zestawów zasobów, bardziej rygorystycznego taktowania oraz założeń specyficznych dla silnika, budowanych przez lata optymalizacji dla konsol.

Technicznie dokładne podsumowanie musi zatem zachować obie strony tego kamienia milowego. AnyPS5 usunął każdą obecnie śledzoną niewiadomą ze swojego dekodera shaderów, co stanowi wartościową pracę fundamentową.

Nie ustanowił pełnej translacji shaderów, pełnej równoważności GPU, szerokiej kompatybilności bibliotek systemowych ani niezawodnej obsługi katalogu PS5.

Trzy sygnały pokażą, czy AnyPS5 zmniejsza lukę

Kolejne istotne dowody będą pochodzić z testów semantycznych, odtwarzalnej kompatybilności gier oraz mianownika bibliotek systemowych, który wytrzyma szersze obciążenia.

Pierwszym sygnałem jest zweryfikowane zachowanie instrukcji. Współtwórcy potrzebują testów pokazujących, że zdekodowane operacje są tłumaczone na poprawny SPIR-V i odpowiadają oczekiwanemu wynikowi sprzętowemu.

Zasady współtworzenia projektu już wskazują ten kierunek. Zmiany w shaderach muszą odwoływać się do precyzyjnego źródła technicznego lub pomiarów z prawdziwego sprzętu, podczas gdy nierozstrzygnięte przypadki pozostają wyraźnie oznaczone jako dług techniczny.

Większy zbiór zautomatyzowanych testów semantycznych wzmocniłby znaczenie wartości 100%. Przekształciłby tracker z mapy rozpoznawania w dowód dotyczący przetłumaczonego zachowania.

Najbardziej użyteczne raportowanie rozdzielałoby co najmniej trzy stany: zdekodowane, przetłumaczone i zweryfikowane sprzętowo. Taki podział pozwoliłby obserwatorom zobaczyć, czy głębia implementacji dogania jej szerokość.

Jeśli liczby przetłumaczonych i zweryfikowanych instrukcji będą szybko rosły, kamień milowy będzie wyglądał jak początek skoncentrowanej fazy prac nad poprawnością. Jeśli rozpoznawanie pozostanie jedyną kompletną warstwą, luka kryjąca się za nagłówkiem pozostanie.

Drugim sygnałem jest odtwarzalna lista kompatybilności. Więcej gier musi działać w publicznych kompilacjach z udokumentowanym sprzętem, systemami operacyjnymi, ustawieniami, znanymi wadami i zakresem testów.

Uruchomienie tytułu powinno pozostać odrębne od dotarcia do menu, wejścia do rozgrywki, działania z docelową liczbą klatek na sekundę i ukończenia gry. Łączenie tych stanów ukryłoby więcej, niż by ujawniło.

Przydatny wpis powinien także wskazywać zewnętrzne poprawki lub ręczne kroki. Natywna konwersja staje się znacznie bardziej przekonująca, gdy inny użytkownik może odtworzyć rezultat bez prywatnego kodu lub nieudokumentowanych modyfikacji.

Przejście od jednej zweryfikowanej lekkiej gry do kilku niezależnych tytułów pokazałoby, że architektura daje się uogólnić. Obsługa wymagającego tytułu 3D zapewniłaby znacznie silniejszy test obciążeniowy.

Trzecim sygnałem jest relacja między wykrytymi a zaimplementowanymi funkcjami systemowymi. Zgłoszone 84,76% wygląda zachęcająco, ale jego wartość zależy od stabilności mianownika.

Jeśli testowanie większej liczby gier ujawni wiele dodatkowych funkcji, surowy procent może spaść. Będzie to oznaczać lepsze poznanie platformy, a nie regres.

Liczy się to, czy nowo odkryte funkcje otrzymują dokładne implementacje i odblokowują rzeczywiste oprogramowanie. Wyniki na poziomie tytułów powinny poprawiać się wraz z rozszerzaniem mapy interfejsów.

Obserwatorzy powinni także śledzić, czy awarie przesuwają się głębiej w wykonanie. Gra przechodząca od błędów startowych do menu, rozgrywki i dłuższych sesji może pokazywać znaczący postęp, nawet zanim zostanie uznana za grywalną.

Pokrycie shaderów AnyPS5 zasługuje na uwagę, ponieważ usuwa jedną szeroką klasę natychmiastowych awarii. Każda śledzona instrukcja może teraz wejść do dekodera zamiast zatrzymywać się jako nieznane dane wejściowe.

Trudniejsza faza zaczyna się po tym rozpoznaniu. Twórcy muszą wykazać, że przetłumaczone shadery zachowują się poprawnie, zastępcze biblioteki odtwarzają oczekiwane usługi, a skonwertowane gry pozostają stabilne przy pełnych obciążeniach.

Dla programistów, badaczy zachowywania oprogramowania i technicznie ciekawych graczy najlepsze pytanie nie brzmi już, czy tracker może osiągnąć 100%. Już to zrobił.

Pytanie brzmi, jaki odsetek z tych 1 166 instrukcji przejdzie testy semantyczne w rzeczywistych grach, na różnych komputerach PC, bez ukrytych poprawek. Warto obserwować zweryfikowaną listę zgodności oraz testy shaderów oparte na sprzęcie. Wyniki przesądzą, czy kamień milowy AnyPS5 stanie się fundamentem dla natywnych gier PS5 na PC, czy pozostanie imponującą statystyką dekodera.