Ryujinx (Switch Emulator) Update(blog.ryujinx.org)
blog.ryujinx.org
Ryujinx (Switch Emulator) Update
https://blog.ryujinx.org/progress-report-november-2022/
26 comments
I hadn't seen this before and I was curious what approach Ryujinx and Yuzu (mentioned here) take to emulate the GPU. Both appear to emulate the actual hardware rather than patch the guest to intercept graphics calls in some way. This includes recompiling Maxwell shader machine code into host-compatible shaders (GLSL or whatever). Impressive.
This is fairly common in many console emulators, see:
- PS3 (Nvidia RSX): https://github.com/RPCS3/rpcs3/blob/master/rpcs3/Emu/RSX/rsx...
- PS4 (AMD GCN): https://github.com/AlexAltea/orbital-qemu/blob/master/hw/ps4...
The hardware is known ahead of time, so console platforms take advantage of that: GPU drivers allocate a context and hand it over to userspace which can do nearly anything it wants with it (abstraction layers are quite thin), and graphics APIs are essentially a 1:1 mapping of the hardware.
Because of that there's little difference between emulating the API or emulating the GPU (the subset of the GPU accessible through the API).
The only major difference I'd say is emulating the entire GPU (including VM, GART/IOMMU, display controller, multi-contexts, etc.) vs just emulating a single GPU context (which feels quite similar to implementing a graphics API).
- PS3 (Nvidia RSX): https://github.com/RPCS3/rpcs3/blob/master/rpcs3/Emu/RSX/rsx...
- PS4 (AMD GCN): https://github.com/AlexAltea/orbital-qemu/blob/master/hw/ps4...
The hardware is known ahead of time, so console platforms take advantage of that: GPU drivers allocate a context and hand it over to userspace which can do nearly anything it wants with it (abstraction layers are quite thin), and graphics APIs are essentially a 1:1 mapping of the hardware.
Because of that there's little difference between emulating the API or emulating the GPU (the subset of the GPU accessible through the API).
The only major difference I'd say is emulating the entire GPU (including VM, GART/IOMMU, display controller, multi-contexts, etc.) vs just emulating a single GPU context (which feels quite similar to implementing a graphics API).
Fascinating, and still an impressive technical lift especially for hobby projects without full time funding.
If you want to visit crazy-land, check out Dolphin's UberShaders; the gamecube had a mostly fixed function but super configurable graphics pipeline that can't really be translated well to modern hardware, and this caused lots of stutters and annoyances, so eventually some mad lad decided to write a GPU shader that just simulated the entire pipeline flow, no more translation or anything. Won't work on your laptop very well, but if you have an 8 year old dedicated GPU or newer, fixes the problem outright.
A similar thing was actually done in n64 world for RSP emulation, another proto-gpu device with it's own highly configurable microcode. First it was emulated in CPU with AngryLion, and someone else I think made it all run in compute shaders on the GPU, meaning you can FINALLY play nearly every n64 game accurately rendered, upscaled rendering if you want, and no slowdowns or bugs or glitches from more rare techniques, like the spy gadget in perfect dark.
A similar thing was actually done in n64 world for RSP emulation, another proto-gpu device with it's own highly configurable microcode. First it was emulated in CPU with AngryLion, and someone else I think made it all run in compute shaders on the GPU, meaning you can FINALLY play nearly every n64 game accurately rendered, upscaled rendering if you want, and no slowdowns or bugs or glitches from more rare techniques, like the spy gadget in perfect dark.
"Ubershaders: A Ridiculous Solution to an Impossible Problem"
https://dolphin-emu.org/blog/2017/07/30/ubershaders/
Hah. Yes. I appreciate people doing all of this because from a preservation standpoint these emulators will likely be maintainable long after working original hardware becomes very rare.
Hah. Yes. I appreciate people doing all of this because from a preservation standpoint these emulators will likely be maintainable long after working original hardware becomes very rare.
I’ve used yuzu a bit before but not Ryujinx. Does anyone know what the main differences between them are? Looks like both still require owning a hacked switch which is quite a barrier to entry.
From the end-user perspective: I see Yuzu and Ryujinx differences as mostly about game compatibility (I keep both around). I personally don't know any feature one has over the other that might drive people to a specific one.
As far as the requirement to own a Switch, it mostly has to do with being able to decrypt games to play them and system OS apps for services they provide to games. If they were to ship these keys or firmware blobs, they'd be at risk of litigation from Nintendo versus providing documentation on how to obtain the keys and firmware legally. Some of the firmware files might be able to be reimplemented in the future depending on patents and the like.
As a side note, the files required to play _can_ be found online, probably by searching the firmware version plus the filename from Yuzu/Ryujinx docs. (The keys are firmware version specific, and I think tools like RyuSAK let you get both keys and firmware, but this definitely isn't the legal way to go about it )
As far as the requirement to own a Switch, it mostly has to do with being able to decrypt games to play them and system OS apps for services they provide to games. If they were to ship these keys or firmware blobs, they'd be at risk of litigation from Nintendo versus providing documentation on how to obtain the keys and firmware legally. Some of the firmware files might be able to be reimplemented in the future depending on patents and the like.
As a side note, the files required to play _can_ be found online, probably by searching the firmware version plus the filename from Yuzu/Ryujinx docs. (The keys are firmware version specific, and I think tools like RyuSAK let you get both keys and firmware, but this definitely isn't the legal way to go about it )
> both still require owning a hacked switch which is quite a barrier to entry
This has not been necessarily the case for years.
This has not been necessarily the case for years.
By which you mean that if you have a fusee-glecee (sic) compatible switch, no hardware mods are necessary beyond turning it on holding a usually inaccessible button combination, right? After that, everything is perfectly legal backup and format shifting.
What are the conditions under which do you still need a hacked switch?
https://github.com/Ryujinx/Ryujinx/wiki/Ryujinx-Setup-&-Conf...
> Your Switch keys and either your dumped firmware or recent game cartridge untrimmed XCI
> Your dumped Nintendo Switch games or homebrew
You don't need a hacked switch if you can find the homebrew apps / games / firmware on the internet and if you can find a donor set of keys. But that enters questionable territory
> Your Switch keys and either your dumped firmware or recent game cartridge untrimmed XCI
> Your dumped Nintendo Switch games or homebrew
You don't need a hacked switch if you can find the homebrew apps / games / firmware on the internet and if you can find a donor set of keys. But that enters questionable territory
Fortunately, it's way easier to dump keys/etc from recent eras of of consoles than consoles of old.
How do you dump keys from newer versions of the switch that fixed the old way?
There's enough difference in performance and stability it's worth using both if you're into Switch emulation. They can have different performance and bugs for different games. For example, on my hardware Yuzu has a difficult time maintaining a good framerate on Mario Odyssey and it also has an almost half-second input lag with that game. Ryujinx has neither of those problems.
Ryujinx is using C#, which is kind of neat, given that on computing it seems one needs to prove a point to make it clear for others.
Why do this kind of software use .Net? Shouldn't this be implemented with portability in mind?
.NET is pretty portable. It can run on most popular platforms.
Where would you be running this where you’re also blocked by net support?
Where would you be running this where you’re also blocked by net support?
It runs on Windows, macOS and Linux, how much more portable do you want it to be?
Android, iOS, Fuchsia
.NET also runs on Android and iOS so Ryujinx could support them in the future. Most emulators written in C/C++ don't run on all of those platforms either.
They appear to distribute Windows, Linux, and macOS builds. I'm not plugged into the .NET/Mono scene, but the download (the Linux one at least) appears to be an AOT-compiled ELF file, with no dynamic dependencies (well, aside from possibly dlopen()ing things at runtime) on .NET/Mono components. I was able to run it without installing the Mono runtime or any libraries.
.NET is portable, .NET Framework isn't.