Chi segue attentamente lo sviluppo dell’emulatore Yuzu sarà di certo a conoscenza del supporto per l’emulazione della CPU Multicore introdotto solo da pochi giorni dal developer Blinkhawk.

Come molti di voi sapranno, Yuzu è considerato un emulatore HLE (emulazione di alto livello). Ciò significa che invece di eseguire il vero sistema Switch OS (noto anche come Horizon), il programma si limita a creare semplicemente la propria versione del sistema operativo, costruita interamente da zero.

Proprio come per i PC, la console Switch dispone di più core (4, in realtà) e Horizon OS può eseguire più attività in parallelo su questi core utilizzando un costrutto del kernel noto come thread.

Yuzu si limitava ad emulare il comportamento della console Switch utilizzando un singolo core (questo a causa delle limitazioni nel kernel preso dal vecchio progetto Citra dedicata all’emulazione della console portatile 3DS). Ciò aveva portato anche ad un fabbisogno assurdamente elevato della CPU.

Con l’introduzione del supporto per l’emulazione della CPU Multicore ora saremo in grado di emulare la CPU utilizzando 4 thread, uno per ogni core della CPU Switch.

Emulazione CPU yuzu

L’emulazione e il kernel della CPU di yuzu erano fortemente basati su quelli di Citra. Il kernel emulava il comportamento esterno del kernel della Switch ma differiva notevolmente dal sistema operativo della console.

Invece di salvare contesti e passare da un thread guest a un altro all’interno del kernel,è stato utilizzato un meccanismo all’interno del kernel di Citra che emulava lo stesso comportamento ma con un sistema complesso di stops e callbacks.

Non solo, ma nella tradizione tipica degli emulatori precedenti, yuzu utilizzava qualcosa che prendeva il nome di cycle timer. Un timer di ciclo è un meccanismo per emulare il tempo sulla console contando ogni istruzione ospite eseguita e aggiungendola alla CPU tick globale.

Questi tick possono quindi essere trasformati in unità di tempo come i nanosecondi utilizzando la frequenza della CPU dell’ospite.

Svantaggi

Il modello Citra andava perfettamente bene per l’emulazione a single core, era preciso, semplice e funzionava perfettamente per il 3DS in quanto utilizzava solo uno dei suoi due core per app e giochi. Tuttavia, nel caso di yuzu, questo non andrebbe bene.

Switch è un sistema molto più complesso e moderno che spinge 4 core della CPU, dove 3 vengono utilizzati per app e giochi. Non solo, ma la pianificazione è più solida e può essere utilizzata in modi più interessanti e più complicati. L’utilizzo del modello di Citra per la pianificazione era tutto possibile in yuzu, ma presentava alcuni difetti:

• Il codice non corrispondeva al sistema operativo Switch e anche se aveva lo stesso comportamento, era difficile tenere traccia delle modifiche e replicarle.
• Il codice era molto complesso in quanto vi era un callback per tutto ed era difficile da mantenere. Questo modello sarebbe estremamente difficile da eseguire su più thread host.

Prometeus

Prometheus è il nome in codice interno per lo sviluppo di questa funzione ed è una rielaborazione totale di tre cose:

• Pianificazione del kernel
• Gestione dell’avvio
• CPU management

Prometheus mira a garantire che l’emulazione si comporti come sulla console Switch mentre abbina il codice con il codice OS originale della Switch, e, come sottoprodotto, è stato aggiunto a yuzu il supporto multicore dell’host che utilizza il timing dell’host. Il timing dell’host è solo yuzu che utilizza l’orologio interno (dell’utente) dell’host per il timing.

La funzione multicore di Prometheus è una bestia in termini di gestione dei thread. Originariamente yuzu veniva utilizzato nei 2 migliori thread: uno per la CPU e uno per la GPU emulata.

Tecnicamente si potrebbe utilizzare anche un singolo thread per ciascuno, uno per l’interfaccia utente, uno per la registrazione, uno per il driver GPU host e uno per il driver audio host, ma per il momento ignoriamoli.

Con il multicore, ora ci sono 6 thread in uso: quattro per la CPU, uno per il timer e uno per la GPU emulata. Vale la pena notare che il core 4 della CPU viene utilizzato raramente. Di questi 6, effettivamente 5 thread hanno un uso considerevole, ma non tutti funzioneranno costantemente.

Pianificazione

Prometheus è stata una grande impresa che si è articolata in due fasi: fase di pianificazione e fase di sviluppo.

La fase di pianificazione è stata interamente dedicata allo studio della configurazione attuale per farla funzionare con questo nuovo schema. Questo è accaduto all’incirca nell’arco di 8 mesi, ed era principalmente legata solo alla ricerca e al brainstorming.

Durante questa fase, Blinkhawk ha affrontato molteplici sfide e considerazioni per lo sviluppo. Ha iniziato a studiare altri emulatori che già eseguivano l’emulazione multicore come Cemu, RPCS3 e Ryujinx.

Tutti questi emulatori differivano nei loro approcci al multicore. Alcuni hanno usato Fibers per thread guest, 1:1 guest-host kernel thread, timing del ciclo o timing dell’host. Nell’informatica, le fibers sono fili di esecuzione leggeri (Wikipedia).

Per yuzu, inizialmente avevamo in programma di utilizzare Fibers e timer per cicli. Abbiamo scelto Fibers rispetto ai thread del kernel perché la modifica di una Fibra comporta un peggioramento dei 50 cicli della CPU host, mentre un thread del kernel può richiedere migliaia di cicli e non vi è alcuna garanzia che il sistema operativo host inizierà a eseguirlo immediatamente.

Nel caso dei timer di ciclo per yuzu multicore, hanno finito per essere piuttosto un dolore. I timer di ciclo presentano molti vantaggi rispetto ai timer di host:

1. Sono deterministici,
2. Non perdono lo stato host e
3. Avanzano sempre per ogni istruzione che vengono eseguiti i timer di ciclo.

Abbiamo provato molti modelli teorici per i timer di ciclo multicore ed erano tutti piuttosto difficili da configurare pur avendo difetti.

Purtroppo, i timer di ciclo non funzionano troppo bene per le impostazioni multicore, perché è molto difficile mantenere tutti i core avanzando allo stesso ritmo ed emulare con precisione al minimo. Per tutti questi motivi, abbiamo invece optato per il timing dell’host.

Cosa aspettarsi con i giochi?

Non tutti i giochi utilizzano il multithreading in modo efficace e sfruttano al massimo la CPU della console Switch. Alcuni giochi, come Super Mario Odyssey, utilizzano a malapena i core 1 e 2, eseguendo tutta l’elaborazione nel core 0, facendo in modo che non ottengano nulla dal multicore.

Tuttavia, giochi come Breath of The Wild presentano un certo incremento nelle prestazioni, anche se si crede siano fortemente vincolate da un singolo componente, come per l’emulazione della GPU.

La GPU emulata dipende da quattro cose:

1. La velocità single-core della CPU. Un singolo core della CPU host converte tutti i comandi dalla GPU ospite (Switch) in comandi GPU host (Utente). Quindi, avere una CPU con grandi velocità single-core è molto utile.
2. La velocità del bus GPU, yuzu fa molto affidamento sulla larghezza di banda disponibile nel bus GPU. Questa è la velocità con cui i dati vengono caricati da e verso la GPU e varia a seconda della generazione PCIe e delle corsie allocate.
3. La qualità dei driver della GPU. I driver AMD per OpenGL sono terribili mentre quelli di NVIDIA sono fantastici.
4. La stessa GPU host, che si tratti di NVIDIA, AMD o Intel.

Infine, tieni presente che anche la velocità della RAM, la quantità di RAM e il tipo di processore all’interno del sistema influenzeranno l’esperienza di gioco. La versione iniziale potrebbe utilizzare memoria aggiuntiva (da 100 Mb a 3 Gb a seconda del gioco).

Problemi noti

L’audio potrebbe risultare più lento durante l’esecuzione di un gioco in multicore, per cercare di limitare questo problema provare ad attivare la funzione Audio Stretching.

Fonte: yuzu-emu.org