Online il nuovo report sui progressi raggiunti dall’emulatore Yuzu a dicembre. Yuzu è un emulatore open source in continua evoluzione e con build disponibili per PC Windows, Linux e macOS.

Il progetto è stato avviato nella primavera del 2017 da bunnei, uno degli autori originali del popolare emulatore Citra 3DS. L’emulatore Yuzu ha iniziato il suo primo ciclo di sviluppo come fork di Citra a causa delle somiglianze tra la console Switch e la console 3DS.

Durante i primi mesi di sviluppo, il lavoro è stato svolto in privato e il progresso è stato particolarmente lento. Tuttavia, quando il reverse engineering della console Switch e lo sviluppo di homebrew divennero popolari, anche il lavoro su Yuzu iniziò a decollare.

In quest’ultimo report verranno evidenziate le modifiche nel kernel, l’aggiunta di nuovi input e la nuova interfaccia utente con le prime modifiche applicate per completare la riscrittura della cache del buffer.

Miglioramenti generali e correzioni di bug

Il developer epicboy ha corretto diversi bug, due di questi hanno interessato freeze e crash di Katana Zero e Yoshi’s Crafted World (quest’ultimo presenta ancora diversi problemi grafici).

Corretta anche la modalità di accesso ai buffer, che porta per la prima volta all’esecuzione di giochi come DELTARUNE Chapter 1, Dragon Ball FighterZ e Wonder Boy: The Dragon’s Trap.

Con il rilascio della versione 27.20.100.9126 del driver Windows, Intel ha aggiunto il supporto non solo per il tanto necessario VK_EXT_robustness2, ma anche per VK_EXT_custom_border_color, migliorando le prestazioni e la stabilità con la precedente estensione e risolvendo i problemi di rendering in The Legend of Zelda: Breath of the Wild.

Il developer toastUnlimited intanto ha fornito le prime build AppImage, semplificando notevolmente il processo di installazione all’interno delle distribuzioni Linux.

AppImage elimina i tanto temuti problemi di dipendenze ripristinando il supporto per Ubuntu 18.04, Debian Buster, CentOS 8 e molte distribuzioni precedenti.

Durante il tempo trascorso dalla riscrittura della cache delle texture in Early Access, sono state corrette diverse regressioni. Uno dei più importanti legato principalmente alla runa della telecamera in The Legend of Zelda: Breath of the Wild.

Qui è il developer Rodrigo ad aver corretto il trasferimento delle informazioni riguardanti due diversi valori per la dimensione della stessa texture, denominati pitch e width.

In precedenza il programma non riusciva a trasferire correttamente le informazioni necessarie tra di loro poiché le considerava texture diverse. Modificando questo comportamento, entità come animali, fiori, nemici, ecc.. ora vengono registrate correttamente dalla telecamera.

Si sono verificati alcuni arresti anomali durante l’uscita da Yuzu correlati al processo di telemetria. Per eliminare il bug, il developer Tobi ha portato una correzione da Citra cambiando il tipo di AddField in una stringa.

Un problema comunemente segnalato era che le modifiche alla configurazione andavano perse in caso di crash di Yuzu, qui lo sviluppatore toastUnlimited ha modificato questo comportamento per salvare semplicemente le impostazioni correnti prima di avviare un gioco.

Il developer Morph ha inoltre implementato i nuovi font OSS che Rei ha messo insieme. Con questo, gli utenti non dovranno più eseguire il dump del firmware Switch per ottenere i caratteri dei pulsanti appropriati. Il processo di dumping del firmware è ancora necessario per i giochi con contenuti relativi a Mii.

Pulsanti ZL e ZR al posto delle sole lettere

Aggiunto +/- ai caratteri

Alcuni giochi segnalano un handle sbagliato del dispositivo durante l’invio di segnali di vibrazione, come NEKOPARA Vol. 3 (non cercare questa serie su Google). Lo sviluppatore Morph ha corretto anche questo problema convalidando gli handle del dispositivo prima dell’uso.

Riscrittura del kernel

Il kernel di Yuzu ha ricevuto importanti modifiche questo mese, incentrate sul refactoring del codice per la gestione e la sincronizzazione dei thread.

Il developer bunnei ha iniziato a lavorare su questi cambiamenti due mesi fa. Anche se un po’ tecniche, queste modifiche sono risultate essenziali per un’emulazione accurata della console Nintendo Switch. Queste modifiche hanno portato ad un miglioramento nella qualità del codice di Yuzu che ne hanno facilitato lo sviluppo.

Innanzitutto, c’è un miglioramento per Yuzu che ne garantisce l’accesso sicuro alla memoria attraverso i thread. Una Race Condition si verifica quando più thread sono in esecuzione contemporaneamente e un thread modifica i dati mentre un altro thread vi accede.

Le Race Condition possono causare comportamenti errati o imprevisti: un thread può recuperare dati parziali o addirittura sovrascrivere le modifiche apportate da un altro.

Yuzu emula la memoria interna del Nintendo Switch utilizzando un tipo di struttura di dati astratta chiamata Page Table, che funziona come uno strato virtuale tra la memoria fisica e quella emulata.

Mappa questi indirizzi in una “tabella contigua” che consente al programmatore di accedere facilmente alla memoria senza controllare dove la memoria effettiva memorizza il tutto.

La maggior parte delle operazioni di gestione della memoria sono state scritte prima dell’implementazione della CPU multicore e della GPU asincrona.

Allora c’era solo un singolo thread, quindi non c’erano protezioni per l’accesso alla memoria thread-safe. Il developer bunnei ha introdotto un blocco in questo PR per alleviare una Race Condition in cui si accedeva ai dati nelle pagine di memoria mentre la GPU stava operando su di esse.

Bunnei ha anche riscritto lo scheduler del kernel. I sistemi operativi moderni eseguono contemporaneamente molti processi, tuttavia, un singolo core della CPU può elaborarne solo uno alla volta.

Lo scheduler è una parte essenziale del kernel, in quanto si occupa di scambiare l’accesso della CPU ai diversi processi e di scegliere in quale ordine questo avviene. Questo renderà il kernel di yuzu più fedele a Horizon OS.

In seguito a questa riscrittura, bunnei ha rielaborato il modo in cui le chiamate di servizio venivano implementate in yuzu, allocando le chiamate nei propri thread di servizio individuali.

Molti servizi sono in esecuzione in background su Nintendo Switch. Sono responsabili dell’inizializzazione e della gestione di attività specifiche, come audio, grafica, input dell’utente, networking, ecc.. e Yuzu emula questi servizi tramite HLE – High Level Emulation.

Ciò significa che, invece di scaricare il codice binario di queste routine dal Nintendo Switch e tradurre le loro istruzioni in modo che un PC possa eseguirle, il programmatore reimplementa la funzionalità di questi servizi in C++.

Pertanto, HLE funziona come una “scatola nera”: questi servizi vengono chiamati ogni volta che c’è una richiesta dai giochi, e inviano (o chiedono) i dati corrispondenti, anche se internamente possono essere diversi da come il servizio è stato originariamente implementato all’interno dell’hardware.

Tuttavia, fino a quando le informazioni richieste o inviate tramite il servizio sono valide ed elaborate in modo appropriato, il sistema viene emulato correttamente.

Questi processi di servizio sono indipendenti l’uno dall’altro, quindi i giochi li chiamano in modo asincrono. Prima di questa soluzione, tutti questi servizi venivano elaborati nel thread CoreTiming, un thread utilizzato per elaborare eventi in determinati momenti futuri (ad esempio, quando un frame completa il rendering).

Ciò significava che i giochi avrebbero chiamato questi processi, ma non sarebbero stati elaborati fino a quando il thread CoreTiming non fosse stato eseguito, il che ha comportato l’accumulo di queste richieste in una coda e probabilmente l’introduzione di ritardi se la coda non veniva svuotata abbastanza velocemente.

Grazie alle modifiche apportate ora, ognuno di questi processi è stato spostato nel proprio thread, così da elaborarlo più rapidamente. Un vantaggio immediato di questa modifica è che i tempi di caricamento migliorano in modo significativo e anche il ritardo di input viene ridotto.

Ma un altro vantaggio importante è che questa implementazione è più accurata, poiché assomiglia al comportamento dei servizi in Nintendo Switch.

L’emulazione GPU ora viene eseguita anche sul proprio thread, che è sincronizzato su push e flush della GPU. Ciò significa che la GPU asincrona può essere disaccoppiata dal multicore e queste impostazioni possono essere attivate indipendentemente l’una dall’altra.

Infine, come continuazione dei precedenti modifiche, arriva la riscrittura delle primitive di sincronizzazione del kernel, ovvero Synchronization Objects, Condition Variables e Address Arbiters.

Una spiegazione approfondita del funzionamento di questi meccanismi va oltre lo scopo di questo rapporto, ma essenzialmente sono strumenti utilizzati dai thread in processi diversi per comunicare tra loro ed essere sincronizzati correttamente.

Il vantaggio principale di questi cambiamenti è che molto del codice che veniva trasferito da Citra (e che richiedeva importanti soluzioni alternative per farlo funzionare correttamente con multicore) è stato modificato a favore di meccanismi più appropriati per come funziona Yuzu, oltre a renderlo più vicino a come funziona Horizon OS su Nintendo Switch.

Andando di pari passo con queste modifiche alla sincronizzazione, epicboy ha introdotto un PR per incorporare un gestore di syncpoint per nvdec.

Questo utilizza gli strumenti menzionati in precedenza per implementare un meccanismo di sincronizzazione GPU-CPU più accurato, è fondamentale evitare condizioni di competizione quando le operazioni asincrone vengono eseguite dall’emulatore durante la decodifica di un video.

Modifiche all’interfaccia utente

Infine, una modifica dell’interfaccia utente molto necessaria, il supporto della lingua. Grazie al lavoro svolto da Tobi e da molti, molti membri della comunità da tutto il mondo, ora possiamo offrire supporto per 11 lingue diverse, oltre a variazioni regionali.

Tutti sono invitati ad espandere l’elenco delle lingue disponibili.

Per i nostri amanti della riga di comando o delle scorciatoie, Morph ha aggiunto argomenti alla riga di comando. Le opzioni attuali sono:

• yuzu.exe "path_to_game" – Lancia un gioco in path_to_game.
• yuzu.exe -f – Avvia il gioco successivo a schermo intero.
• yuzu.exe -g "path_to_game" – Lancia un gioco in path_to_game.
• yuzu.exe -f -g "path_to_game" – Lancia un gioco in path_to_game a schermo intero.

Sentiti libero di creare scorciatoie sul desktop di tutti i tuoi giochi!

Pensando ai nostri digitatori veloci, toastUnlimited ha aggiunto diversi tasti di scelta rapida per l’accesso alla barra dei menu. Ora, ad esempio, un utente può premere Alt + F, R, INVIO per caricare il gioco giocato più di recente.

german77 ha aggiunto l’opzione per ridimensionare la finestra di yuzu a 1920×1080, oltre al tradizionale 1280×720. Ciò garantisce un perfetto rapporto pixel 1: 1 con giochi 1080p nativi durante il gioco in finestra, per quelli con display ad alta risoluzione.

Modifiche agli input

Il developer german77 ha riportato una serie di miglioramenti agli input.

L’aggiunta di un modo per invertire l’asse di uno stick analogico era un problema che non ci aspettavamo di avere sui controller Xbox e PlayStation, ma alcuni marchi alternativi non sembrano seguire le stesse specifiche. Ora se fai clic con il tasto destro su di un asse, hai la possibilità di invertirlo.

Questo è anche un ottimo modo per invertire una telecamera se un gioco non lo consente nelle sue impostazioni, ad esempio in Star Wars Jedi Knight II: Jedi Outcast.

I trigger analogici a volte venivano mappati invertiti a ciò che l’utente intendeva. Per evitare brutti momenti, ora il programma prende due campioni durante la mappatura di un trigger analogico, per determinare meglio la direzione del movimento. Questo è stato portato da Citra.

Alcuni giochi come Voez e The Room richiedono gesti tattili specifici e per ottenere ciò è stato aggiunto il supporto multitouch. Con questo, yuzu ora offre supporto per un massimo di 16 input tattili con la tastiera, il touch screen o tramite i servizi UDP.

Lavoro preliminare per la riscrittura della cache del buffer

Anche se purtroppo non abbiamo potuto darti un regalo di Natale sotto forma di Buffer Cache Rewrite (o BCR in breve), il lavoro preliminare necessario per averlo pronto è iniziato.

Rodrigo ha le mani impegnate per ripulire il TCR recentemente fuso in Mainline, l’attuale lavoro interno e test sul BCR, e i suoi primi passi con Project Hades.

Andremo in profondità una volta completata la BCR, ma una delle funzionalità richieste è avere accesso a Vulkan in ogni momento per utilizzare interop, una funzionalità del driver che consente agli sviluppatori di incrociare codice tra diverse API grafiche su prodotti Nvidia e AMD. In questo modo, Vulkan può essere utilizzato da OpenGL se offre una soluzione migliore a un problema.

Un cambiamento piuttosto interessante necessario è relativo a Dynarmic. Mascherando i dati in tre bit di puntatore inferiori prima di leggerli, Rodrigo ora può memorizzare le informazioni richieste dalle tabelle delle pagine senza la necessità di utilizzare un blocco, risparmiando tempo prezioso di esecuzione e, al massimo, circa 128 MB di memoria di sistema.

Infine, ulteriore granularità nelle pagine della CPU. Questo PR consente di informare se la CPU o la GPU ha modificato un intervallo di dati nella pagina CPU.

Se l’intervallo rilevante è stato modificato dalla CPU, deve essere caricato sulla GPU. I processori che supportano il set di istruzioni BMI1 otterranno un leggero miglioramento delle prestazioni, questi includono Intel Haswell (Gen.4) o più recenti e AMD Piledriver (2nd Gen. FX)/Jaguar o più recenti.

Progetti futuri

Non è una sorpresa, ma il Buffer Cache Rewrite è prossima al rilascio. Sono previsti miglioramenti delle prestazioni e della stabilità in Vulkan, mentre i miglioramenti del kernel continuano ad essere una priorità assoluta.

Fonte: yuzu-emu.org