Rpcs3: Feature Request: RPCS3 on ARM architecture
I know most of you will be facepalming, raising the ban hammers, and laughing, but before you close this, hear me out at least (please): ARM64 is coming soon, and 3.0+GHz ARM processors will be happening in the foreseeable years. ARM processors will also have improved microarchitectures as manufacturers learn that the old IPW vs. IPC has to let up and ARM processors must depend on cycles and more power. The Xiamio Mi Pad is a tablet featuring an ARM SoC with NVIDIA, AKA NVIDIA Tegra K1, which has OpenGL 4.4 support, 192 stream processors, and comes with a 2.2 GHz CPU that can be overclocked to 2.5 GHz. The guy who invented Play!, the alternative PS2 emulator to PCSX2, is very much considering and agreed to work on getting a JIT dynarec on ARM/Android for testing. Dolphin, the Gamecube/Wii emulator, runs near perfect on the latter, with just some optimizations needed.
Assuming RPCS3 doesn't even have a stable dynarec for Intel, wouldn't now be the best time to consider cross-platform capabilities (before it's too ingrained and tailored to Intel)? For example, one could implement an ARM v7/v8 capable build with some dynamic recompilation, and/or the interpreters.
I realize the massive requirements TODAY, but in several years who knows if ARM processors are soon to reach comparability to Haswell i7s. My assumption is just that if you carried on and tailored RPCS3 just to one CPU architecture (Intel), you may end up in a rut like PCSX2, where they have no possible plans of ever getting it on other platforms, despite being stagnant for more than five years. Does anyone ever plan on having RPCS3 maybe someday in the future running on other processors, platforms, etc.? If so, one should at least consider that, despite ARM's very poor results now, when RPCS3 possibly gets somewhere stagnant along the line ARM64/3.0+GHz/etc. processors may hold their own and be somewhat capable of this. All I ask is that you consider this ... thanks.
ghost
All 12 comments
We won't do any step in the opposite direction. :wink:
But until someone developer actively works on it, let's consider this issue as won't fix.
AlexAltea
on 31 Jul 2014
I don't know. Maybe a "longterm" tag or something like it would be more appropriate.
Bigpet
on 31 Jul 2014
Yeah, sounds better.
AlexAltea
on 1 Aug 2014
Now 3 years later, is there some strong enough ARM CPU+GPU board / machine?
ruthan
on 30 Nov 2017
Well, we still doesn't have a decent emulator for the ps2 on arm...
tanpro260196
on 30 Nov 2017
Nope.
ARM devices can barely run Dolphin as of today, PS3 emulation on current ARM CPUs would be a performance disaster, even on Snapdragon 835.
Maybe when RPCS3 is more optimized and stronger hardware is available.
AniLeo
on 30 Nov 2017
Well, we still doesn't have a decent emulator for the ps2 on arm...
Now we have DamonPS2, using stolen code, but it seems to work, somehow.. But yeah it would take years, we still not have any ARM CPU with high TDP, Nvidia Jetson is still 15W device, if im not wrong..
In theory it should not matters if emulator will translate PowerPC to x86 or to ARM. Doplhin is doing the same..
ruthan
on 14 Jan 2018
Yeah, but Dolphin doesn't emulate a console with a Cell processor at 3.2GHz with 2PPEs+6SPEs(+1)
AniLeo
on 14 Jan 2018
Yeah, but Dolphin doesn't emulate a console with a Cell processor at 3.2GHz with 2PPEs+6SPEs(+1)
Despite having little knowledge about Dolphin, I want to bring up the fact that they have to deal with MMU and RPCS3 doesn't, since you guys just HLE sys_memory_allocate and return a valid pointer into the host process.
Performance aside, I'd bet there's hordes of guys waiting to play their PS3-exclusive visual novels on their phones. That's not very demanding and should run fine in most ARM-based systems.
AlexAltea
on 14 Jan 2018
There were some more discussions on this since in #staff-off-topic. https://discordapp.com/channels/272035812277878785/483198470275203072/593493062005686336~~
Edit: Since a link to a private channel isn't the most helpful (and this is a public repo), I'll try and summarize what was talked about there. Do note that I myself am not skilled in the topic, so I'll just paraphrase rui's, elad's and others' thoughts.
Pros:
- the BE byte order could prove to be an advantage
- Cell-related stuff would mostly work thanks to LLVM
Cons:
- we use many x86-isms, so there'd still be a lot of code that'd need to be rewritten
- the current memory violation-based approach would need a complete rethinking / redo
- the texture cache would need a significant rewrite
- ASMJIT wouldn't work, and any JIT stuff used by LLVM neither (mostly the TSX stuff)
- ARM CPUs are more weakly ordered than x86 ones, which might cause significant issues and would probably require a lot of extra barriers placed
- rewriting the RSX would be a pain in the ass in general (not even mentioning the driver quality on Android)
I myself wonder if UMA would help too, since that'd at least (in theory) remove the need for texture flushing. This makes me think that some of the architectural differences could even prove to be useful, personally. Would need a further (and extensive) investigation.
dio-gh
on 8 Oct 2019
Is it worth having a list of known 'code roadblocks' that would prevent ARM compilation (i.e. down to the code file, and potentially function call level)?
I think the weaker ordering of the ARM CPUs might 'help' us to identify a few race conditions that we don't have proper guards around.
I've already been looking a little bit at some of the intrinsics that we have around the place, and potentially migrating them across to utilise SIMD Everywhere (https://github.com/simd-everywhere/simde). That should reduce the burden of us implementing similar instructions in non-x86-64 platforms.
bevanweiss
on 4 Sep 2020
Apple moving to arm could be interesting too
clienthax
on 4 Sep 2020
Related issues
uaqlover
路
3Comments
xiangzhai
路
3Comments
Asinin3
路
3Comments
Nezarn
路
3Comments
elad335
路
3Comments
Most helpful comment
Apple moving to arm could be interesting too