Il primo report del 2024 per l’emulatore Yuzu sembra aver portato miglioramenti significativi della GPU, oltre a importanti aggiornamenti per il porting Android e altre correzioni per i driver.
La sezione Vulkan riguarda principalmente cambiamenti grafici e correzioni dei driver. I driver NVIDIA della serie 540 presentavano un problema di crash durante la compilazione di specifici shader in giochi, come ad esempio alcune cutscene e scenari in Bayonetta 3.
https://twitter.com/yuzuemu/status/1745200416319823953
Dopo un’indagine, è emerso che il problema non risiedeva nei driver, bensì in una compilazione errata nel compilatore di shader di yuzu per le operazioni di gradiente di texture.
Il bug causava un’interpretazione errata dei gradienti come interi anziché float, portando a crash nei giochi. La soluzione implementata ora forza l’utilizzo di tipi F32 per rispettare la specifica SPIR-V, consentendo agli utenti di mantenere i driver aggiornati senza problemi di crash.
Altri miglioramenti riguardano problemi grafici su Android, come lo schermo tagliato a metà in modalità portatile per il gioco Fight’N Rage, risolto correggendo la gestione di swizzle e window origin adjustments.
Inoltre, Super Mario 3D All-Stars aveva problemi di prestazioni durante l’introduzione su driver non-NVIDIA e non-Mesa, risolti modificando la gestione del swapchain.
Un problema di presentazione limitata su Android è stato risolto, consentendo l’uso sicuro della presentazione asincrona, migliorando le prestazioni su hardware meno performante e riducendo la latenza di input.
Un ultimo fix riguarda la gestione dei clip distance nei giochi che utilizzano queste informazioni, come Portal, garantendo la corretta dichiarazione e inizializzazione dell’array di distanze di clip.
Infine, è stata corretta la gestione del pitch per le texture compressate, risolvendo problemi di rendering in giochi come THE KING OF FIGHTERS XIII GLOBAL MATCH e il minigioco Eatsa Pizza di Mario Party Superstars.
OpenGL
Un problema residuo (tra tanti) per l’ormai datata API OpenGL riguardava un bug nelle ombre di Metroid Prime Remastered. Implementando la precisione della query del contatore, precedentemente vista in Vulkan, anche in OpenGL, è stato risolto questo problema.
Gli utenti di OpenGL hanno ottenuto un altro successo con l’implementazione di due correzioni per Xenoblade Chronicles 3.
Questo è particolarmente importante per gli utenti AMD, sia su Windows che su Linux, poiché molte GPU AMD non potevano evitare esplosioni di vertici eseguendo il gioco con Vulkan nella regione di Pentelas della trama principale e nel DLC Future Redeemed.
In primo luogo, l’implementazione della macro DrawTransformFeedback, equivalente in OpenGL a DrawIndirectByteCount in Vulkan, ha risolto il problema delle particelle.
In secondo luogo, correggendo l’associazione del feedback di trasformazione da strides a sizes, si è impedito che l’erba nel gioco diventasse una sorta di abominio demoniaco dello spazio.
Grazie a queste modifiche, gli utenti AMD che riscontravano il bug degli esplosioni di vertici nella regione di Pentelas/DLC ora possono giocare in sicurezza utilizzando OpenGL.
Tuttavia, ulteriori ottimizzazioni sono state apportate da epicboy al driver OpenGL proprietario di AMD, rilasciato a luglio del 2022, eliminando varie soluzioni temporanee poco piacevoli presenti nel codice di yuzu, migliorando così le prestazioni complessive.
Avventure Android e kernel con vantaggi
Una delle caratteristiche del kernel Linux, dalla quale beneficiano le distribuzioni GNU/Linux e Android, è la sua flessibilità e il progresso costante realizzato dalla comunità e dai contributori.
In questo contesto, si menziona l’estensione del kernel Linux MADV_REMOVE, che consente di liberare un determinato intervallo di pagine di memoria, “creando un buco” nell’intervallo specificato di memoria.
Grazie al lavoro di byte[], l’emulatore può sfruttare questa estensione per eliminare la necessità di avere immediatamente dopo l’avvio di un gioco 3 GB di RAM libera e per ridurre significativamente i tempi di avvio.
La memoria non è un problema per la maggior parte degli utenti con 16 GB di RAM di sistema (a meno che ci siano troppi processi in background), ma per gli utenti con 8 GB o meno che utilizzano un sistema operativo con kernel Linux (Linux desktop o Android), ciò riduce notevolmente i requisiti immediati di memoria, consentendo persino a Celeste di funzionare su dispositivi con 4 GB.
Mentre il sistema non deve più fornire l’intero ammontare di 3 GB all’avvio del gioco, il gioco richiederà comunque lentamente quella quantità mentre viene eseguito.
Tuttavia, ciò potrebbe essere sufficiente per consentire ai dispositivi con 8 GB, o addirittura 6 GB (che non viene supportato ufficialmente, ma che gli utenti li utilizzano comunque), di raggiungere il prossimo punto di salvataggio.
Pare che solo The Legend of Zelda: Tears of the Kingdom richieda ancora 12 GB su dispositivi compatibili con ASTC (dispositivi Android o GPU Intel) per essere giocato in modo sicuro.
Per chi utilizza Windows invece, pare ci siano solo brutte notizie. Il kernel Windows non ha un equivalente di MADV_REMOVE, quindi se si dispone di un dispositivo di fascia bassa con una piccola quantità di RAM, Linux è la scelta giusta.
Risoluzione 4K
La risoluzione? No, peggio, più folle della densità di pixel. Ricordate Paper Mario: The Origami King? Un bel gioco, grafica accattivante e umorismo divertente.
Questo gioco ha una situazione unica, il suo codice CPU ARM è illegale. Non illegalità “FBI APRI”, ma del tipo “non in grado di eseguirsi nativamente su sistemi contemporanei a causa di una differenza nella gestione dell’allineamento del puntatore dello stack” illegale.
La console Switch cancella un bit hardware che controlla l’allineamento del puntatore dello stack e genera un’eccezione, ma praticamente ogni altro sistema operativo lo imposta e non c’è modo di disabilitarlo senza una modifica del kernel.
Ciò significava che i dispositivi moderni non potevano eseguire questo gioco con NCE abilitato. Almeno fino ad ora.
Utilizzando il parser ARM di Dynarmic, byte[] ha analizzato le istruzioni responsabili del crash a causa dell’errore di allineamento che questo gioco produce e le interpreta in software.
Il risultato? Tre mila ottocento cinquantotto righe di codice aggiunte per ottenere un gioco che non si rende correttamente su Android all’avvio e che ha ancora bisogno di un file di salvataggio per superare l’introduzione.
Quindi, uno sforzo inutile? Con byte[]? Mai. Il gioco non veniva visualizzato correttamente perché l’emulatore associava immagini float con un tipo di sampler non corrispondente.
Forzando l’uso di float per tutti i formati di pixel nella cache degli shader che non sono dichiarati esplicitamente come interi, i driver mobili ora sono in grado di renderizzare correttamente i fratelli Mario nella loro intera gloria.
Un déjà-vu leggero con la correzione della serie di driver NVIDIA 540 precedentemente menzionata, giusto? Questo lavoro ha aggiunto ulteriori centottantaquattro righe di codice, portando a un totale di quattromila e trentotto righe di codice, 4K, spese su carta origami, solo per Android.
Altre modifiche alla GPU specifiche per Android
La build Android di yuzu si è trovata di fronte a un problema particolare relativo alle prestazioni lente nella decodifica video di giochi come SUPER MARIO ODYSSEY, noto per i suoi tutorial video.
Il colpevole era il download non necessario di alcune texture di memoria che erano comunque destinate a essere sovrascritte. Alcuni aggiustamenti al codice DMA da parte di Blinkhawk hanno risolto il problema, migliorando le prestazioni!
Un altro problema che ha colpito le build Android quando sono stati introdotti inizialmente era una regressione riguardante il filtro di antialiasing FXAA.
Si è scoperto che la correzione per la banda di colore che FXAA sperimentava sull’hardware desktop (implementata da byte[] nel giugno precedente) ha omesso di aggiornare il renderpass al formato corretto.
Utilizzando correttamente il formato VK_FORMAT_R16G16B16A16_SFLOAT per il renderpass, GPUCode ha risolto il problema.
Il servizio JIT della console Switch consente ai giochi di scrivere nella memoria del codice durante l’esecuzione, il che normalmente non sarebbe possibile a causa delle restrizioni della piattaforma.
Attualmente, ciò è utilizzato solo per gli emulatori ufficiali Nintendo 64 in Super Mario 3D All-Stars e nella collezione Nintendo Switch Online.
Utilizzando correttamente i gestori di memoria del codice, il servizio JIT può funzionare con il backend NCE di yuzu, consentendo all’utente di eseguire giochi dalla libreria Nintendo 64 – Nintendo Switch Online.
Ancora una volta, un ringraziamento a byte[] per aver reso possibile l’esecuzione di un emulatore all’interno di un altro emulatore.
Come continuazione del progresso di novembre nell’ottimizzazione della stabilità di Mali a causa della mancanza di supporto per nullDescriptor, byte[] ha aggiunto ora la soluzione temporanea per non passare viste nulle.
nullDescriptor è stato aggiunto con l’estensione Vulkan VK_EXT_robustness2, nel 2020, per la versione 1.1 dell’API. Attualmente Vulkan è alla versione 1.3.
Dato che la funzionalità ha il supporto hardware nativo su tutte le GPU compatibili con Direct3D ed è semplice da emulare nel driver, non è chiaro il motivo per cui questa non è stata ancora implementata.
I driver Turnip sono ancora in fase di sviluppo da parte degli sviluppatori di Mesa – sebbene tipicamente abbiano buone prestazioni e renderizzino bene, sono ancora in fase di sviluppo.
Un caso che ha dimostrato ciò è stato come una modifica per migliorare la compatibilità del driver Mali ha causato un regresso in Turnip in risposta. Momento Mali #4? No. Questo è accaduto il mese scorso.
Questo influisce specificamente sulle GPU della serie Adreno 610 quando si utilizzano i driver Turnip. La soluzione di byte[] al problema è quella di utilizzare deliberatamente l’API Vulkan in modo non corretto per Turnip mentre si attende che Mesa risolva la questione. Ora gli utenti di Adreno 610 possono eseguire nuovamente i driver Turnip.
Interfaccia utente specifica per Android e modifiche varie
L’utente t895 ha implementato con successo le Game Properties, una nuova funzionalità che può essere acceduta tenendo premuto a lungo su un gioco nella lista. Questa funzione fornisce accesso alle seguenti opzioni:
- Una pagina di informazioni del gioco per controllare l’ID del programma, lo sviluppatore del gioco, la versione in esecuzione e il percorso della ROM del gioco.
- Impostazioni specifiche per il gioco, con l’opzione di ripristinare una determinata impostazione al valore predefinito globale.
- Un selettore del driver specifico per il gioco.
- Un gestore degli add-on per installare, abilitare e disabilitare aggiornamenti, DLC e mod.
- Un gestore di dati di salvataggio che consente agli utenti di esportare o importare salvataggi specifici per il gioco.
- Un’opzione per eliminare tutti i dati di salvataggio relativi a quel particolare gioco.
- Un’opzione per cancellare la cache della pipeline di quel particolare gioco.
- Un pulsante di avvio per selezionare una configurazione globale o personalizzata.
Questo colma una delle principali lacune presenti nella build Android di yuzu. Le uniche impostazioni rimanenti sono un gestore dei contenuti per eliminare i contenuti installati e un’interfaccia utente per la mappatura del controller.
t895 continua a lavorare per portare la versione Android di yuzu al livello di funzionalità della versione desktop, considerando le esigenze specifiche della piattaforma mobile. Alcuni dei cambiamenti recenti includono:
- Nascondere il comando Fastmem se il debug della CPU è disabilitato per evitare confusione.
- Esposizione dell’impostazione di filtraggio anisotropico nelle opzioni grafiche per migliorare la qualità visiva in diversi giochi con un costo minimo delle prestazioni.
- Centrare il titolo dell’impostazione dello switch quando non è presente alcuna descrizione.
- Implementazione del backend audio Oboe specifico di Android, che previene la troncatura dell’audio durante il cambio delle uscite audio o l’avvio di una registrazione video dello schermo.
- Equalizzazione del file di configurazione
config.iniper renderlo compatibile sia con le build desktop che con quelle Android.
Inoltre, è stata affrontata una limitazione del kernel Linux relativa al numero di chiamate di sistema mmap, risolvendo un problema che colpiva alcuni giochi basati su Unreal Engine 4.
Byte[] ha introdotto una soluzione che inserisce uno strato tra la tabella delle pagine software e il sistema di mappatura dell’host, monitorando costantemente le allocazioni di heap fatte dai programmi e riciclando automaticamente alcune mappature meno utilizzate, riducendo il numero di mappe e prevenendo il crash dell’intero programma su Linux.
Questa modifica consente ai giochi basati su Unreal Engine 4 di essere eseguiti senza problemi su sistemi Linux, inclusi desktop e dispositivi Android, senza la necessità di disabilitare impostazioni cruciali come fastmem e NCE.
Allocazione dell’heap di memoria
Come il kernel Linux a volte può essere sbagliato
Il kernel Linux presenta una limitazione relativa al numero massimo di chiamate di sistema mmap che un programma può effettuare.
Il valore massimo predefinito è di 65530, che, secondo il meme, “dovrebbe essere sufficiente per chiunque”, ma nella pratica non è sempre così.
In generale, i giochi per console Switch richiedono la quantità di heap di memoria disponibile, la riservano tutta e successivamente eseguono una suddivisione da questa riserva a livello di sistema operativo man mano che utilizzano la memoria.
Questo processo è già ben supportato quando si utilizza l’indirizzamento host-mappato (comunemente noto come fastmem) su sistemi operativi basati su Linux, poiché richiede solo poche chiamate per mappare i blocchi di memoria fisica che compongono l’heap.
Tuttavia, i giochi basati su Unreal Engine 4 non seguono questa pratica. Invece di riservare immediatamente tutta la memoria disponibile, riservano piccoli blocchi dal kernel su richiesta.
Se viene utilizzata solo la tabella delle pagine software, non ci sono problemi, poiché i blocchi non comportano chiamate a mmap.
Quando yuzu utilizza l’indirizzamento host-mappato, l’emulatore propaga tutte queste mappature nello spazio degli indirizzi host.
Questo di per sé non sarebbe normalmente un problema, se non fosse per il fatto che Unreal Engine 4 può allocare centinaia di migliaia di piccoli blocchi di heap, superando facilmente il limite del kernel e facendo crashare l’intero programma.
Yuzu non è l’unico progetto colpito da questa limitazione arbitraria; è stata una lamentela che persiste da molto tempo.
Per aggirare questa limitazione, byte[] inserisce uno strato tra la tabella delle pagine software e il sistema di mappatura host, tenendo costantemente traccia delle allocazioni di heap effettuate dai programmi e riciclando automaticamente alcune mappature meno utilizzate, causando alcune interruzioni, ma è meglio di un crash di gioco.
Questa raccolta ridurrà il numero di mappature a circa la metà del limite di 65530 che la maggior parte dei sistemi presenta.
In questo modo, i giochi basati su Unreal Engine possono essere giocati in modo sicuro su sistemi basati su Linux, inclusi desktop e dispositivi Android, senza dover disabilitare fastmem e NCE, due impostazioni cruciali per le prestazioni che nessuno vuole disattivare.
Progetto Leviathan, applet e divertimento con gli input
Come di consueto, german77 ha continuato a lavorare sulle funzionalità di input e sugli applet nativi.
Innanzitutto, una soluzione per gli Amiibo con autorizzazioni in sola lettura. Se un programma li montava in sola lettura, yuzu non accedeva a nessuno dei loro dati crittografati e poteva segnarli come danneggiati, anche se non era il caso.
Poiché i dati in sola lettura sono impostati in fabbrica, saltare il controllo di corruzione consente l’uso di montaggi in sola lettura in giochi come The Legend of Zelda: Tears of the Kingdom.
In seguito, un annuncio. german77 ha iniziato a lavorare su una riscrittura del codice HID (dispositivi di interfaccia umana), chiamato Project Leviathan, con l’intenzione di migliorare ulteriormente l’accuratezza dell’emulazione dell’input di yuzu.
Finora sono stati compiuti solo lavori preliminari, ma alcuni risultati sono già stati messi in servizio.
La prima parte completata è l’emulazione di AppletResource, che consente agli sviluppatori di iniziare a lavorare sul supporto multiprocesso in un prossimo futuro, così come su altre risorse necessarie come AppletResourceUserId, o semplicemente aruid.
Inoltre, german77 ha implementato il codice necessario per consentire la creazione di più istanze della memoria condivisa HID, eliminando un vecchio accorgimento e alleggerendo il carico del kernel per la gestione della memoria condivisa, consentendo così di avere una singola istanza di memoria condivisa per aruid.
Un altro punto che sta cominciando a prendere forma grazie a questa riscrittura di HID è la creazione di oggetti, più specificamente, InitializeVibrationDevice, che causava il blocco di giochi come Rocket League.
Ma german77 non è stato l’unico a lavorare sull’input questo mese: il nuovo arrivato HurricanePootis ci ha portato una correzione interessante per gli utenti Linux.
Linux gestisce le autorizzazioni hardware a livello di utente. Ad esempio, se per qualche motivo l’amministratore lo desidera, un utente può essere completamente bloccato dall’accesso al gruppo video, audio, ecc..
I dispositivi connessi spesso possono essere accessibili solo dall’utente o dal gruppo root. Sebbene ciò di solito non sia un problema per l’uso del dispositivo, può bloccare l’accesso ai driver personalizzati Joy-Con e Pro Controller implementati da german77, indipendentemente dal fatto che l’utente utilizzi una versione di yuzu appimage o Flatpak.
Aggiungendo una regola udev per concedere l’accesso ai dispositivi hidraw, HurricanePootis ha aggirato questa limitazione.
Modifiche varie
Lavoro preliminare per il supporto multiprocesso
Byte[] ha ristrutturato il modo in cui yuzu emula l’attivazione del core della CPU, semplificando il design dell’interfaccia ARM con l’aggiunta di ben tremila righe di codice.
Questa ottimizzazione consente l’esecuzione simultanea del codice proveniente da vari processi ospiti, un requisito fondamentale per avviare l’implementazione del supporto multiprocesso.
Inoltre, l’emulazione ARM per i processi ospiti ha ricevuto il supporto per multiple istanze di memoria, le quali possono ora coesistere e interagire con diverse sessioni del server. Un passo avanti con ogni richiesta di pull.
Modifiche al core, al kernel e al file system
German77 ha risolto un comportamento inatteso nel gestore del profilo utente, risolvendo problemi legati alla perdita improvvisa del profilo dopo crash dell’emulatore.
Byte[] ha affrontato situazioni particolari nei giochi, come nel caso della trilogia di Batman: Arkham, dove alcuni giochi richiedevano l’installazione degli aggiornamenti per essere giocabili.
Altre modifiche sono state apportate al sistema di file, inclusa la gestione di OpenDirectoryMode per migliorare il supporto di Portal 2.
Modifiche all’interfaccia utente (UI)
German77 ha corretto un problema nelle configurazioni dell’interfaccia utente che impediva il salvataggio della selezione della lingua.
Inoltre, ReillyBrogan ha apportato una piccola modifica per migliorare l’esperienza degli utenti desktop Linux che utilizzano compositori Wayland.
Sezione hardware
Byte[] ha risolto problemi con i driver NVIDIA, rendendo sicuro l’aggiornamento alle versioni più recenti. Si è menzionato un nuovo driver Mesa Vulkan open source, NVK, per hardware NVIDIA Turing e successivo.
Sono state segnalate problematiche con crash su hardware RDNA1 (RX 5000 series) di AMD, mentre Intel non ha ancora fornito una soluzione per un problema segnalato a ottobre.
Viene menzionato un nuovo dispositivo Snapdragon 8 Gen 3 con una GPU Adreno 750, elogiando le prestazioni nonostante il driver mediocre.
Momenti Mali
Sono stati segnalati alcuni problemi con hardware Mali, ma si sottolinea che future generazioni, denominate “Panthor”, avranno un driver Mesa ufficiale.
Sono stati evidenziati miglioramenti nella rete di supporto di Turnip, con nuovi rilasci che portano miglioramenti alle prestazioni e alla stabilità.
Progetti futuri
Il supporto multiprocesso per GPU SMMU è quasi completato grazie a Blinkhawk, con ulteriori dettagli previsti nel prossimo rapporto.
Fonte: twitter.com
