Yuzu: Nintendo Switch Emulator
github.com
github.com
I know /nothing/ about emulator development, but I wonder what the performance of a Switch emulator written for the M1 using Metal for graphics would look like. I'd expect the Switch and the M1 both being ARM would be an advantage? Would be curious to learn more if anyone in this space wants to weigh in.
Modern emulators are a lot like Wine these days where they are just translating the custom api calls to something that works on a desktop OS.
It actually depends more on the memory ordering. To speed up the running of x86 apps, the M1 has a strong memory-ordering mode designed to match x86.
https://wololo.net/2021/09/08/release-spine-ps4-emulator-v-2...
FWIW, M1 Macs are also one of the few ARM platforms that will let you[0] actually install regular GNU-and-Wayland desktop Linux. I think the current crop of Windows on ARM machines will also let you install Linux, of course. But most Android hardware ranges from mildly to very hostile to users who want regular Linux - even if there's a bootloader unlock, the hardware is going to require all sorts of extra vendor-proprietary drivers that won't work with a standard distro. This also ties in with what I said before about backwards-compatibility across multiple SoCs.
The reason why people treat the M1 as separate from all other ARM hardware is because it actually acts like a computer; providing the performance and control you expect from something bearing the name. Most other ARM vendors are not aiming to provide that.
[0] You do have to sign the kernel with your Owner key, but that's manufacturer-supported, so it counts.
Also random thought, but can the opposite be achieved? That is, installing Orbis (PS4 OS, based on FreeBSD) on generic PC hardware?
According to Google, Orbital is the one using QEMU.
Most emulators interpret the machine instructions in software so there wouldn't be any advantages there. Some are now incorporating dynamic recompilation but I doubt it would have any noticeable impact on ARM vs x86.
I've been running the PCSX2 PS2 emulator on M1 (rendering using either OpenGL backend or Software), it runs my favorite game SSX Tricky great, including joystick support, sound and smooth graphics.
As for the CPU architecture, probably the dynamic recompilation step that turns ARM code to x86 could be skipped.
Just to show, how viable it is, there's a closed source emulator for Android that's probably base on Yuzu (with surprising good performance):
https://www.youtube.com/watch?v=Ex_AArUJ8cY
The suspicion coming from it having the same bugs as yuzu itself.
I don't know if Switch could be emulated with Wine-like approach, if not, it would be tricky to intercept syscalls without an ARM-to-ARM DBT. Performance impact should be minimal though.
Both seem to be possible, since arm64 uses fixed instruction length. I don't think svc calls can be trapped in-process with user privileges, and it's even less likely it can be done in a portable way.
So probably some level of source-patching needs to take place, but it requires just a high-level understanding of the code, not a full decompilation-recompilation.
You don't need a DBT, VMs on arm64 are very cheap. You can just use Hypervisor.framework really.
just for clarity, cpu/audio emulation needs predictive performance, you can't have that with C# due to the managed nature of it
That said, there's tons of games written in less than optimal languages for major portions of the game, like Naughty Dog games in the PS1/PS2 era used a lisp based language for a lot of things
We've used this on all Unity projects I've been part of and it really makes a difference in performance.
I think it should be possible to achieve predictable performance, though it depends on the qualities of the JIT, it won't work if it's constantly recompiling or allocating stuff that needs to be garbage collected of course.
Same idea applies to a JIT. Getting the best performance may require tuning the JIT to only run at certain times (e.g., before starting a level).
Do you want to inline this function in your loop? Yes and no, i.e. you might be taking up some valuable registers in your loop, increasing register pressure. Time to pull out the profiler and experiment, wasting your precious time.
Managed languages have the advantage of knowing the landscape of your program exactly, as __that__ additional level of managed overhead can help the VM automatically split your code into hot and cold paths, having access to the runtime heuristics of your program allows it to re-JIT your hot paths, inline certain functions on the fly, etc.
If you think about wine and dxvk, it's pretty much the same concept, without the need to emulate a CPU.
On the contrary, Higan uses low level emulation(LLE), wherein the actual hardware of the system is emulated as faithfully as possible, which is very CPU intensive.
But yeah, the progress reports are now mostly fixes for very low level stuff like emulating a specific hardware cache just right or matching the /exact/ semantics of AMR64 floating point for certain titles.
[1]:https://wiki.dolphin-emu.org/index.php?title=Wii_Menu#Keyboa...
Additionally, modern console might use the same hardware as PCs themselves (I don’t know how close they are), so let’s say if a console is using x86 already on a linux-based machine, then your job to write emulator would be to only implement whatever missing on the os, passing through everything else to be ran natively
Interfacing with the graphics hardware is often “translated” to more conventional DirectX/OpenGL APIs.
[1] https://dolphin-emu.org/blog/2021/09/07/dolphin-progress-rep...
This means that less accurate emulation can still result in a playable game, whereas missing the timing of how the SNES CPU moved data to the PPU could render scanline-specific register twiddling used on actual hardware into gobbledygook.
But even still, higan/bsnes were notoriously CPU heavy because it took a different approach to emulation (perfect low-level emulation of the actual hardware system). Even with SNES, if you were willing to relax perfection you could get very playable games with much less CPU usage, as shown by emulators of the 90s.
In fact that was my own intro to emulation, zSNES playing SNES FF6 on Pentium-class hardware. The Switch has evolved a lot since the SNES, but so too have desktop computers.
Might be wrong about this but I believe SNES emulators are now approaching "perfect" emulation which is to exactly emulate the hardware down to every defect. This is what can slow things down but will give you perfect reproduction of games. A lot of modern emulators use hacks (sometimes game specific) to achieve the performance you see but can result in experiences not like the game on a native console.
All that being said though, the teams working on these emulators really matters in terms of the performance they're gonna eek out of modern day computers.
Those also have some significant tradeoffs between emulation accuracy and speed, though because they were focused on playable games at speed, not necessarily perfect accuracy.
The later emulators have tried to do low level emulation to get accurate cycle counts and whatnot to make it as close as possible to a real SNES.
It's relatively easy to get the first 90%, but each 1% after that doubles the difficulty. This is especially true on older machines where the code tended to be hand-written assembly. When working with modernish machines where there's a SDK for C/C++, high level emulation tends to be much easier to accomplish-- and this is why there wasn't anything even remotely resembling accurate for N64 until the last few years. It was only feasible recently.
Gamecube, Wii, Switch, X360, PS3, PS4 -- these are machines that will remain HLE for a long time. Cycle accuracy will be arduous and require CPU resources we likely won't have for a long while.
Purpose built hardware can do many operations in a single or fewer clocks. For example reading an input, doing some math to it, and outputting it. A modern microcontroller can do some of that pretty fast, but change over to something like a PC and you're actually fighting a lot of delays in processing. For example you cant just thread out the various hardware components and emulate them efficiently. The OS is going to schedule when those threads execute. Therefore you get locked into one core and are dependent on single clock speed. Even then you're fighting inefficiencies in emulating real hardware.
It's much more like an interrupt driven PC architecture where things just...happen, instead of hard polling, ta, say, every vblank or the end of every scanline.
This is also why they can run at different resolutions, even different aspect ratios. (For instance, most N64 games will quite happily run at 16:9 1080p/60 fps. There might, depending on the instructions used, be some distortion on things like menus, but overall it works surprisingly well.
In some cases games would even rely on facts what happened after each cycle of a 3 cycle CPU instruction.
Fortunately for emulator writers, that's not possible on modern hardware. They operate much more like a series of independent boxes, and you can't do such exact cycle counting. That means you can do things like rewrite ARM into x86 and just run the CPU, and only need an approximate count of how many cycles it has done.
Modern machine emulators (outside of hypervisor based virtualization) don't use cycle-accurate emulation. Instead they use high level techniques such as intercepting 3d draw routines and translating them into OpenGL/DirectX/Vulkan API calls. In addition, they take heavy advantage of JIT to compile the code to more close to baremetal instructions for the target architecture, which isn't viable for cycle accuracy.
One of the main reasons older machines require LLE is that they're cycle intolerant and rely on specific timing for many effects (although, you can still get 90% there with most, just being "close enough"). Newer machines (from the PSX on, for the most part) use pipelined architectures and are strongly interrupt based, so timing is generally less important.
Tl;Dr - No matter the case, cycle-accurate is the ideal case. But newer machines are just more tolerant to bad timing than older machines.
Yuzu (Nintendo Switch Emulator) Progress Report January 2021 - https://news.ycombinator.com/item?id=26095834 - Feb 2021 (89 comments)
Nintendo Switch Emulator - https://news.ycombinator.com/item?id=25522454 - Dec 2020 (12 comments)
Yuzu-Emu/Yuzu: Nintendo Switch Emulator - https://news.ycombinator.com/item?id=20200098 - June 2019 (1 comment)
Yuzu – Nintendo Switch Emulator - https://news.ycombinator.com/item?id=16150777 - Jan 2018 (171 comments)
There are many different ways to legally obtain games to run on emulators, Switch included.
I’m absolutely a fan of engineering feats like these being made more accessible for educational purposes. Even in college, I built a NES emulator on an FPGA.
But to argue that it’s primary motive is not to facilitate (and potentially profit from) piracy is not grounded in reality.
Much on the contrary, I'd say piracy is a console emulators most common use. But it's still fine. All that matters is there's a possibility they're being used for good things.
If someone does something bad he's responsible for it, not the creator of the tools he used. Even if you don't like what most people use something for, just the possibility of one person doing it right is much more than enough reason for it to built. We call this individual freedom, and it's much more important than (game publisher's financial) security.
About piracy, when I think about it, piracy is big part of my computer childhood, otherwise, I wouldn't afford to do anything with computers.
As a marketer, I can even see the benefits of "free distribution of content" to people that wouldn't buy it anyway, and you're still building your brand on those people - they will, eventually down the line, buy your IP if they had good experiences with it.
I became a GTA fan thanks to it, and to modding, when started to be able to afford games I bought into the series.
If I haven't developed the emotional relationship with the game, nowadays I wouldn't care less about it.
Does it also enables(or make it much easier) way to play pirated games? yes. And only that defines whether it enables piracy or not.
But to dump the keys from a hacked switch, you had to already have a hacked switch which you could have just loaded the games on to which would run better than emulating it. So right now, there is little reason to use this project other than curiosity but in 10 years it will be the easiest way to play switch games when hacked consoles become too rare and nintendo doesn't care anymore.
I can only assume they intentionally leave this last hurdle up so the general public are locked out until the development is done and the console is commercially obsolete.
That's where the group that validates rom dumps gets their name from: No-Intro. Because old rom dumps used to modify the rom to add an intro advertising whoever cracked or dumped the rom. https://en.wikipedia.org/wiki/Crack_intro