Disponibile il nuovo report sui progressi raggiunti dall’emulatore RyuJinx affrontati durante il mese di ottobre, e che sembra vada ad affrontare alcuni problemi legati ad alcuni titoli ostici come ad esempio Luigi’s Mansion 3.
Luigi’s Mansion 3 presenta alcune imperfezioni visive in determinati contesti, come il rendering dell’atrio intrecciato e l’utilizzo di una modalità di risoluzione dinamica particolarmente aggressiva, che hanno rappresentato fonti di disagio nel corso del tempo.
October progress report is now live!https://t.co/ocVY7gQcoB
— Ryujinx (@RyujinxEmu) November 17, 2023
Nel rapporto del mese precedente, sono state discusse alcune correzioni apportate alle GPU AMD per affrontare problematiche legate a oggetti e ombre specifici.
Tuttavia, è stato rilevato un caso particolare in cui era evidente che Luigi stesse sperimentando disagi visivi significativi. Il vero problema risiede nei formati delle texture.
Luigi’s Mansion 3 rende questa ombra come un R16Unorm (formato colore), ma poi procede a campionarla come un D16Unorm (formato profondità). Aggiungere il supporto per una dipendenza di copia tra questi formati ripristina l’ombra alla sua forma e durata appropriata.
Anche l’avventura puzzle Cocoon presenterebbe alcuni problemi evidenti, anche se sono stati recentemente isolati ulteriori istruzioni dello shader sulla GPU che non venivano ancora supportavati da RyuJinx.
Anche se solitamente questo non è un grosso problema (solo un avviso nel log della console), questa particolare istruzione stava generando attivamente un codice non valido.
Per correggere questo problema è stato implementato un adeguato supporto per interrogare la quantità di campioni su una texture multisample.
Oltre a Cocoon, un altro obiettivo del team è stato Neptunia GameMaker R:Evolution. La squadra ha affrontato la necessità di gestire la rimozione dei dati dalla memoria delle GPU (VRAM) dopo che il gioco ha concluso il loro utilizzo.
Nell’affrontare questo problema, è emerso un principio fondamentale per lo scarico delle texture: evitare di farlo una volta che la texture stessa è diventata non mappata.
Questa precauzione è cruciale poiché, una volta non mappata, la GPU non ha chiarezza su cosa sia attualmente memorizzato nella posizione di memoria, considerando che la CPU potrebbe aver già sovrascritto quei dati.
L’ignorare questa regola potrebbe portare a fenomeni di corruzione dei dati, evidenziando l’importanza di un corretto processo di gestione delle texture per evitare tali problemi.
Nel caso specifico di Neptunia GameMaker R:Evolution, la violazione di questa regola ha portato a un’alterazione dei dati e, sfortunatamente, a un crash anziché alla produzione di contenuti visivi corretti.
L’adozione di pratiche corrette per evitare tali scarichi non validi ha consentito al gioco di continuare senza intoppi.
Inoltre, è stato affrontato un inconveniente con i driver Radeon 23.2.x di AMD, che ha causato frustrazione nel team.
Nel backend SPIR-V, è stato rilevato un problema di riutilizzo dei parametri delle funzioni in chiamate multiple alla stessa funzione, confondendo il compilatore SPIR-V AMD e risultando in arte astratta anziché in esecuzione corretta delle istruzioni.
L’adozione di un approccio che assegna a ciascuna funzione il proprio set di valori temporanei ha dimostrato di risolvere questa problematica.
NativeAOT è una caratteristica relativamente recente del framework .NET, precedentemente menzionata in diversi rapporti.
Il suo obiettivo principale è colmare il divario tra un ambiente di esecuzione completamente compilato Just-In-Time (JIT), tipico di linguaggi come C# o Java, e un linguaggio completamente compilato come C/C++.
Compilare direttamente il codice C# in codice macchina Ahead of Time (AOT) offre notevoli vantaggi in termini di tempi di avvio e maggiore portabilità su piattaforme in cui potrebbe non essere disponibile l’accesso completo al runtime .NET e al JIT.
Tuttavia, questo approccio comporta un compromesso, poiché alcune funzionalità di .NET, in particolare la capacità di generare codice durante l’esecuzione del programma, vengono sacrificate.
Attualmente, Ryujinx utilizza un JIT per alcune macro GPU Switch, cercando di emettere direttamente il Linguaggio Intermedio .NET (IL) per evitare un percorso più lento tramite un interprete.
Abilitare NativeAOT e quindi bypassare l’interprete comporta una significativa riduzione delle prestazioni in Super Mario Odyssey, con un calo da 90 frame al secondo (FPS) a 75 FPS, rappresentando una considerevole diminuzione del 17%.
La soluzione a questo problema è implementare macro HLE che cercano di corrispondere direttamente alla macro NVN di livello inferiore, anziché lasciarlo emesso a IL.
Con NAoT, ciò riporta le prestazioni di Super Mario Odyssey a 85FPS, anche se ancora al di sotto dei 90FPS menzionati in precedenza, ma il divario di 5FPS è dovuto a fattori aggiuntivi non correlati a queste macro NVN.
In altre notizie, è stata introdotta una soluzione alternativa per i driver GPU che non supportano l’equivalente OpenGL textureGatherOffsets.
MoltenVK tecnicamente riporta di supportare tale estensione, ma in qualche momento tra il rilascio iniziale di macos1 e oggi, un aggiornamento a SPIRV-cross (una libreria utilizzata da MVK per convertire gli shader Vulkan negli shader Metal) ha cercato di utilizzare tale funzionalità, causando il crollo del compilatore metal perché Metal non la supporta.
Questa soluzione alternativa consente nuovamente a Xenoblade Chronicles: Definitive Edition di essere reso (sebbene siano ancora presenti una serie di altri problemi, specialmente nelle versioni più recenti di MoltenVK).
Sifu, un roguelike dal nome molto breve, ha rappresentato una fonte di frustrazione su Ryujinx fin dal suo rilascio molti mesi fa. Sebbene sia visivamente e meccanicamente valido, Il gioco soffriva da tempo di crash casuali.
La causa di ciò risiedeva nel gioco che chiamava in modo problematico una funzione che sostituiva i buffer nel surface flinger (essenzialmente il servizio che crea un unico grande buffer di dati da molti buffer più piccoli).
Mentre il risultato finale di una grande catena di problemi era un crash dovuto a unmemory unmap, la radice era un piccolo problema in un singolo contatore di base che non veniva adeguatamente decrementato.
Assicurandosi che questo contatore venga decrementato in caso di colpi in queste situazioni problematiche, i giocatori di Sifu non devono più trattenere il respiro.
Per coloro che non ne sono a conoscenza, mentre un’operazione di upstreaming è stata completata nei cambiamenti di macOS, ne è stata avviata un’altra.
Il focus attuale è stato portare l’intera funzionalità LDN, su cui il team ha lavorato negli ultimi 3 anni, nei principali rilasci. Questo impegno è emerso con maggiore priorità poiché ora è disponibile più tempo per concentrarsi sulla pulizia e sul reverse engineering del servizio.
Nel mese precedente, è stato implementato il supporto per l’effettiva realizzazione del servizio, con la nota che, pur avendo molte delle funzionalità già operative dal lato ‘Switch’, è ancora necessario trovare un modo per renderle pienamente utilizzabili.
Questo viene attualmente realizzato in due modi nelle build LDN:
- Implementazione personalizzata su internet tramite i nostri server chiamata “RyuLDN”. Questo consente agli utenti di Ryujinx di connettersi tra loro da tutto il mondo, ma ha il limite di essere limitato solo agli utenti di Ryujinx.
- Ldn_mitm è un’alternativa che trasforma la funzionalità di qualsiasi gioco che ha la funzionalità LDN in uno con funzionalità LAN. Ciò significa che qualsiasi vera Switch con il sysmodule ldn_mitm può connettersi a qualsiasi altra Switch equivalente e, in aggiunta, a Ryujinx. Lo svantaggio è che per far funzionare questo metodo, tutti i sistemi devono essere sulla stessa rete, sia essa reale o virtuale.
Poiché il secondo approccio è in definitiva più semplice per il momento, è il primo ad essere reso disponibile nei rilasci principali.
Una modifica che molti utenti su sistemi integrati e a minor consumo energetico (o chi osserva il consumo energetico anziché giocare) potrebbero apprezzare è stata un aggiustamento su come viene segnalata l’aggiunta di una sessione a un dato ServerBase.
In passato, veniva effettuata semplicemente una interrogazione per 1 ms, il che comportava un considerevole “falso” utilizzo della CPU.
Sebbene fosse falso nel senso che il thread si fermerebbe se qualsiasi altra attività lo richiedesse, ciò che non era falso era che costringeva il thread a un uso reale costante, inflazionando la sua presenza durante la profilazione e causando notevoli influenze sul consumo energetico.
Regolando questa logica per segnalare un evento all’aggiunta di una sessione anziché effettuare interrogazioni, l’utilizzo generale della CPU (soprattutto quando l’emulazione è in pausa) mostra notevoli riduzioni.
Tuttavia, i veri guadagni si possono vedere su dispositivi alimentati a batteria come lo Steam Deck. Mario Kart 8 Deluxe, mentre è semplicemente sulla schermata di selezione dei personaggi, vede un taglio nel consumo energetico da 15,8 W a 9,1 W.
Il team sottolinea che non si aspetta che la recente modifica abbia un impatto significativo sulle prestazioni effettive del sistema, considerando che l’utilizzo eccessivo della CPU precedentemente segnalato non era considerato “reale”.
Tuttavia, ritengono che ottenere prestazioni equivalenti con una significativa riduzione del 42% nel consumo energetico rappresenti un successo.
Riconoscono che questi benefici potrebbero variare tra i diversi giochi e indicano che sono in corso ulteriori miglioramenti per ottimizzare la gestione delle attese inferiori al millisecondo in futuro.
Nel contesto di RyuJinx, è stata implementata una funzionalità molto richiesta simile a quella presente di recente in Yuzu. Gli utenti ora hanno la possibilità di aggiungere collegamenti diretti ai giochi sul desktop con un semplice clic.
Basta cliccare con il tasto destro del mouse su un titolo e cercare in fondo al menu contestuale, da cui sarà possibile creare un collegamento per il gioco selezionato con relativa icona direttamente sul desktop attivo.
In secondo luogo, il rapporto di aspetto ora può essere cambiato dalla barra inferiore se si utilizza il frontend Avalonia.
Ciò consente di passare rapidamente tra di essi se, per qualche motivo, il formato 16:9 non è sufficiente a metà sessione ed è necessario che il gioco sia in formato 4:3.
Ultimo, ma certamente non meno importante, la libreria che viene utilizzata per emulare la maggior parte dei servizi del sistema di file – LibHac, è stata aggiornata alla versione 0.19.0.
Nuova versione, nuove funzionalità. `IFileSystem.GetFileSystemAttribute’, un nuovo servizio del sistema di file aggiunto nel firmware 16.0.0, è ora completamente supportato, consentendo a titoli più recenti come Tiny Thor, Cassette Beats e DeepOne di entrare nel gioco.
Ryujinx è costantemente supportato dalla comunità, e gli sviluppatori ringraziano coloro che contribuiscono su Patreon, testano e fanno parte del progetto su GitHub e Discord.
Fonte: blog.ryujinx.org
