Retroarch: [Bounty] Update Dolphin core and port it to ARM64

[natinusala]

The current libretro core doesn't compile on ARM64 targets as it is missing some make rules.

However, the core is heavily outdated compared to the standalone version (~4500 commits, one major version and two years of improvements behind). It has to be rewritten from scratch.

The idea would be to :

1. Update the core so that it's on par with the latest (stable ?) version of Dolphin - don't port from a release, just pick the master branch
   
   
   
   • How is the configuration handled ? The original emulator has ~/.config/dolphin-emu/Dolphin.ini - this config file is required on some platforms
   
   
2. Adapt the makefile so that it builds and works on ARM64 targets (obviously with JIT)

Obviously, upstreaming is preferable if possible. See how the current core is made to see how both the standalone emulator and its libretro core can cohabitate within the same codebase.

Here are some guidelines from degasus, a Dolphin developer :

• Try to minimize the patchset for libretro support and keep it rebase-able.
• Upstream dolphin internal changes. Most of them are likely cleanups and optional feature disabling.
• Don't mix libretro and dolphin-internal patches. Never.

Discussion about the port and this bounty on Dolphin forums : https://forums.dolphin-emu.org/Thread-bounty-for-libretro-dolphin

[natinusala]

Just to be transparent : the main motivation behind this bounty is to have dolphin running on the Nintendo Switch via Lakka and eventually homebrew RetroArch

[mstreurman]

As was posted on the Dolphin dev-forums, one has to keep in mind that the current JITARM64 will be tremendously slow on the Switch, since the current JIT is barely able to run any game at full speed on the much faster Shield TV... One probably has to rewrite the whole core for it to be even remotely viable.

See the comment of the current Android dev JonnyH here: https://forums.dolphin-emu.org/Thread-bounty-for-libretro-dolphin

[fr500]

Actually CPU is running at full clocks on switch linux.

[natinusala]

It reportedly runs at steady 30 FPS on Arch Linux with GNOME.

Edit: well some games do, some games don't. But porting the core and having it upstreamed is a first step towards having it fully optimized

[mstreurman]

@fr500 yet in Linux only runs at around 60% speed without any game breaking hacks/tweaks/settings and even if it runs as fast as the Shield TV you will still have a lot of issues getting games to run fast enough without those hacks. Since the Shield TV doesn't even have enough power to run most games consistently fast enough. Even the reportedly faster XBONEX and PS4pro isn't fast enough and they would be able to run the "optimized" x86_64 version of Dolphin...

But yeah, I would love it to see people work on the different JIT's for Dolphin, maybe there still is some breakthrough to be had that suddenly makes it a lot easier on the hardware. As soon as my wages come in next month I'll back.

[natinusala]

Even if the performance is mediocre on the Switch for now, porting the core still have some advantages :

• It will be ready for updating when the necessary optimizations come
• It will most certainly be used on desktop, either via Lakka or standalone RetroArch - the Switch is only one hardware among others
• It is beneficial for the libretro ecosystem to have another core for a "big" emulator, even more if the support is upstreamed

While _my_ motivation behind this bounty was to run it on the Switch eventually, I'm not alone and I'm sure a lot of people could benefit from this port too.

[iOS4all]

@natinusala you’re absolutely right.
We really hope to get dolphin core running on switch via Lakka.

[chuchuw]

Just added my money to the bounty. I'm happy to see I'm not alone to see dolphin become more and more functionnal. I don't own a Switch, I'm using it on PC.

[tiliarou]

Added a few bucks to the bounty as well ! Very excited to see this being worked on in the near future hopefully !

[ShadyGame]

so there is someone already working on this?

"aliaspider has begun working on a solution to "[Bounty] Update Dolphin core and port it to ARM64".

aliaspider provided the following URL to track his or her progress: https://github.com/aliaspider/dolphin

The bounty can be claimed once the issue gets closed on the original issue tracker. When a bounty claim is submitted, all Backers will be notified.

Thanks,
The Bountysource Team"

[aliaspider]

the port has been completed and merged to https://github.com/libretro/dolphin. prebuilt binaries for linux/windows/osx/android can be downloaded from the buildbot directly or through the online updater.

check https://lakka-switch.github.io/documentation/ for instructions on how to run lakka on the switch. it might take some time until a precompiled dolphin core is added to the official package for lakka-switch so you would have to compile it yourself in the meantime.

[flibitijibibo]

Thanks for doing this! I'm running RetroArch via Flatpak and have a couple notes:

1. The Linux build depends on sndio, possibly because the cubeb library enables it
2. The Linux build also depends on ffmpeg, which I think is just used for AVI dumps.

If those two pieces are disabled I _think_ it should boot and run with the Flatpak version. I'd be interested in seeing the real Wiimote and Wii U GC adapter support as well, but this is still really REALLY nice to see and I hope it gets upstreamed soon.

[aliaspider]

both sndio an ffmpeg are only used in the build if they are actually found when running cmake the first time. if your cross-compile environment differs from your actual runtime environments then that might be an issue yeah.
both are unused in the core of course, they weren't disable because it would just add unnecessary differences to upstream code.

[flibitijibibo]

Doh, should have mentioned this came from the buildbot, not a local build!

[fr500]

Well I guess the buildbot has ffmpeg and sndio in the path...
Linux portable cores are a bad idea for a number of reasons, this is one :)

[aliaspider]

@flibitijibibo I ended up disabling those two dependencies afterall :
https://github.com/libretro/dolphin/pull/30
hopefully that should increase the compatibility of the Linux portable build a bit.

[flibitijibibo]

Excellent, will try this again once it pops up in the nightlies.

[flibitijibibo]

Gave it another try and the good news is on normal human distributions this new core works fine, and fresh Linux installs should be able to run this with no problems. Thanks to @aliaspider for the quick fix!

One thing I forgot about is that Flatpak is, at the moment, deliberately not supporting libudev (?????) so the libudev/libusb dependencies still won't work in their sandbox. You can fuss with those two dependencies in the sandbox if you _really_ want to, but really they just need to fix this in Flatpak and probably the freedesktop runtime as well. (In SDL we can't even do joystick hotplugging right now because of this, it's a real fun time)

[aliaspider]

ping @tjg1 @bionik dickdick Singledad7 ownedlol : the bounty goal has been completed, can you please accept the claim ?

[tjg1]

Done

[bionik]

Done too

[prataczak]

Is there any chance of getting multi disc support added? The standalone version has it. I'd be willing to contribute a little extra to see it implemented, and I know someone else who would too.

Popular multi disc games for GameCube such as Baten Kaitos Origins, Metal Gear Solid: The Twin Snakes, Resident Evil: Code Veronica X (and at least 19 others) are currently unplayable from beginning to end.

[chuchuw]

Tales of Symphonia :)

I think the workaround for now is to extract the save file, put it in the dolphin standalone, launch the game, swap disc, save, reimport the save file.

[prataczak]

Respectfully, if I'm going to go to all that trouble, I might as well be using the standalone all along. :)

[natinusala]

@aliaspider any insight on multi disks ?

[twinaphex]

There are definitely still some rough edges on the Dolphin core, and I could still use help with the Ishiiruka core too on the buildbot server side.