6 ms·

I would love to see a Switch emulator for the M1, although I certainly understand why it'd be a last-priority for emulator developers. I know /nothing/ about e

I would love to see a Switch emulator for the M1, although I certainly understand why it'd be a last-priority for emulator developers. 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.

deleted 5y ago
[deleted]
Gigachad 5y ago
I only know a small amount but from what I have seen, having the same CPU arch is not really that important, as we have seen, you can run x86 apps on the M1 at blazing speeds. The hardware in modern consoles is becoming pretty standard, so the vast majority of effort goes in to emulating the libraries and such the switch comes with. 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.
- schappim 5y ago
  >> CPU arch is not really that important 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.
aufhebung 5y ago
There is an experimental PS4 emulator that ran using QEMU, taking advantage of the fact that the PS4 is x86. Something similar could be done for M1 and ARM. https://wololo.net/2021/09/08/release-spine-ps4-emulator-v-20210901-ps4-emulator-for-linux/ https://wololo.net/2021/09/08/release-spine-ps4-emulator-v-2...
- kaladin-jasnah 5y ago
  How does one GPU acceleration when running on a VM (as I imagine QEMU is doing here)? Also random thought, but can the opposite be achieved? That is, installing Orbis (PS4 OS, based on FreeBSD) on generic PC hardware?
  - mkdirp 5y ago
    This is probably not exactly the same, because I'm assuming the ps3 is maybe emulated very different, but rpcs3 is able to boot up into the XMB. https://www.pcgamesn.com/emulation/ps3-emulator-rpcs3-xmb https://www.pcgamesn.com/emulation/ps3-emulator-rpcs3-xmb
- toastal 5y ago
  Aside: if Apple's M1 processor is ARM-based, why do we bother making the distinction? If anything I feel like this hurts more than it helps because Windows and Linux need better ARM support too.
  - dagmx 5y ago
    I guess because M1 describes the entire platform in shorthand (CPU+GPU+performance characteristics), whereas ARM only describes the CPU instruction set.
  - kmeisthax 5y ago
    Because, quite frankly, ARM silicon is held back by other vendors. Apple is unique in the ARM space in that they actually make an attempt at retaining compatibility across SoC iterations. Linus Torvalds has famously gone on multiple rants about how much of a mess ARM chips are - every new chip usually meaning a full reshuffle of the register map and new drivers everywhere. The work being done on Asahi Linux, on the other hand, is very likely to carry forward to M2, M2 Pro/Max, etc. 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.
tjpnz 5y ago
>I'd expect the Switch and the M1 both being ARM would be an advantage? 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.
erwincoumans 5y ago
Yes, the emu for M1 will likely run very well, and OpenGL 3.x works very reasonable on M1, despite being marked as 'deprecated'. From the issue tracker, they want to use Molten Vulkan (on Metal) and clang lacks some C++20 features they use. 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.
- joshspankit 5y ago
  Upvoting for SSX Tricky. When I got nostalgic for games most of them are EA titles from that era.
  - erwincoumans 5y ago
    Thanks, I'm still hoping for an SSX sequel :)
- ohgodplsno 5y ago
  No emulator wants the burden of maintaining something like an OpenGL 3 renderer. They already struggle to keep the D3D11/Vulkan/Software ones up to date. Anything else is pretty much getting the axe as soon as possible, and pretty much all of those that have an OpenGL renderer use opengl4 or gles2
monocasa 5y ago
Honestly I can see it being a higher priority for switch emulator devs pretty soon. A rpi5 would be in the right neighborhood of being able to emulate the switch when using the virtualization extensions. The CPU is already more than there on the RPi4, just the GPU is a bit anemic. If they have it working against KVM, hypervisor.framework is then an almost trivial amount of work.
torginus 5y ago
Afaik the main issue is not the CPU architecture, but the Graphics APIs. Macos has only very old OpenGL and doesn't support Vulkan at all. And you're right, they probably don't have the effort to spare to implement Metal. 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 https://www.youtube.com/watch?v=Ex_AArUJ8cY The suspicion coming from it having the same bugs as yuzu itself.
- rfoo 5y ago
  > probably the dynamic recompilation step that turns ARM code to x86 could be skipped 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.
  - torginus 5y ago
    I'm not an expert on the ARM64 architecture, or the Switch OS, but from what I can tell, the interface between the OS and the app consists of function calls to the OS api, and syscall-s, that are triggered by the svc instruction. I'd guess the app is statically linked against the OS API, so for the OS calls, the addresses can be patched (or alternatively the emulated OS libs can be mmap-ed to the correct address), and the svc calls can be replaced with a jump to a thunk that emulates it's behavior. 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.
    - londons_explore 5y ago
      Seems like a fragile approach when you can't even be sure about which bits are code and which are data... You might end up patching a svc syscall only to find out that it's actually some constant used in the logic of the game.

deleted 5y ago

[deleted]

Gigachad 5y ago

I only know a small amount but from what I have seen, having the same CPU arch is not really that important, as we have seen, you can run x86 apps on the M1 at blazing speeds. The hardware in modern consoles is becoming pretty standard, so the vast majority of effort goes in to emulating the libraries and such the switch comes with. 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.

schappim 5y ago
>> CPU arch is not really that important 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.

aufhebung 5y ago

There is an experimental PS4 emulator that ran using QEMU, taking advantage of the fact that the PS4 is x86. Something similar could be done for M1 and ARM. https://wololo.net/2021/09/08/release-spine-ps4-emulator-v-20210901-ps4-emulator-for-linux/ https://wololo.net/2021/09/08/release-spine-ps4-emulator-v-2...

kaladin-jasnah 5y ago
How does one GPU acceleration when running on a VM (as I imagine QEMU is doing here)? Also random thought, but can the opposite be achieved? That is, installing Orbis (PS4 OS, based on FreeBSD) on generic PC hardware?
- mkdirp 5y ago
  This is probably not exactly the same, because I'm assuming the ps3 is maybe emulated very different, but rpcs3 is able to boot up into the XMB. https://www.pcgamesn.com/emulation/ps3-emulator-rpcs3-xmb https://www.pcgamesn.com/emulation/ps3-emulator-rpcs3-xmb
toastal 5y ago
Aside: if Apple's M1 processor is ARM-based, why do we bother making the distinction? If anything I feel like this hurts more than it helps because Windows and Linux need better ARM support too.
- dagmx 5y ago
  I guess because M1 describes the entire platform in shorthand (CPU+GPU+performance characteristics), whereas ARM only describes the CPU instruction set.
- kmeisthax 5y ago
  Because, quite frankly, ARM silicon is held back by other vendors. Apple is unique in the ARM space in that they actually make an attempt at retaining compatibility across SoC iterations. Linus Torvalds has famously gone on multiple rants about how much of a mess ARM chips are - every new chip usually meaning a full reshuffle of the register map and new drivers everywhere. The work being done on Asahi Linux, on the other hand, is very likely to carry forward to M2, M2 Pro/Max, etc. 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.

tjpnz 5y ago

>I'd expect the Switch and the M1 both being ARM would be an advantage? 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.

erwincoumans 5y ago

Yes, the emu for M1 will likely run very well, and OpenGL 3.x works very reasonable on M1, despite being marked as 'deprecated'. From the issue tracker, they want to use Molten Vulkan (on Metal) and clang lacks some C++20 features they use. 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.

joshspankit 5y ago
Upvoting for SSX Tricky. When I got nostalgic for games most of them are EA titles from that era.
- erwincoumans 5y ago
  Thanks, I'm still hoping for an SSX sequel :)
ohgodplsno 5y ago
No emulator wants the burden of maintaining something like an OpenGL 3 renderer. They already struggle to keep the D3D11/Vulkan/Software ones up to date. Anything else is pretty much getting the axe as soon as possible, and pretty much all of those that have an OpenGL renderer use opengl4 or gles2

monocasa 5y ago

Honestly I can see it being a higher priority for switch emulator devs pretty soon. A rpi5 would be in the right neighborhood of being able to emulate the switch when using the virtualization extensions. The CPU is already more than there on the RPi4, just the GPU is a bit anemic. If they have it working against KVM, hypervisor.framework is then an almost trivial amount of work.

torginus 5y ago

Afaik the main issue is not the CPU architecture, but the Graphics APIs. Macos has only very old OpenGL and doesn't support Vulkan at all. And you're right, they probably don't have the effort to spare to implement Metal. 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 https://www.youtube.com/watch?v=Ex_AArUJ8cY The suspicion coming from it having the same bugs as yuzu itself.

rfoo 5y ago
> probably the dynamic recompilation step that turns ARM code to x86 could be skipped 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.
- torginus 5y ago
  I'm not an expert on the ARM64 architecture, or the Switch OS, but from what I can tell, the interface between the OS and the app consists of function calls to the OS api, and syscall-s, that are triggered by the svc instruction. I'd guess the app is statically linked against the OS API, so for the OS calls, the addresses can be patched (or alternatively the emulated OS libs can be mmap-ed to the correct address), and the svc calls can be replaced with a jump to a thunk that emulates it's behavior. 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.
  - londons_explore 5y ago
    Seems like a fragile approach when you can't even be sure about which bits are code and which are data... You might end up patching a svc syscall only to find out that it's actually some constant used in the logic of the game.