pcsx_rearmed libretro core - RetroArch's official Miyoo build [REQUEST]

[Apaczer]

Following picoarch's build patch for F1C200S, I started to write Miyoo target (F1C100S) for pcsx_rearmed core here: https://github.com/Apaczer/pcsx_rearmed/commits/miyoo-platform

I left out CFLAGS += -DGPULIB_USE_MMAP -DGPU_UNAI_USE_INT_DIV_MULTINV -D_TRIMUI in makefile.libretro. Of course TRIMUI is build with different toolchains, so no idea what would work on Miyoo.

As I don't have any dev knowledge (only research skills 😅), I welcome anyone interested to add Miyoo platform to official upstream.

This emulator has been succesfully ported to Trimui A66 as libretro core for picoarch frontend by @neonloop (Trimui shares same CPU but double the RAM). People from Trimui community report very similar performance to the standalone version we have on Miyoo.

Considering the last ported realese of standalone PCSX have some compatibility issues (fixed mostly in upstream) and it has major bug where it can't read custom config files (without *.dge scripting), I though adding that emulator as official RA's core might prove a good addition to MiyooCFW.

[jSTE0]

I had a look at building this.

I left out CFLAGS += -DGPULIB_USE_MMAP -DGPU_UNAI_USE_INT_DIV_MULTINV -D_TRIMUI in makefile.libretro.

This is actually unrelated to the toolchain, the first is related to memory mapping, the second is a build-time feature flag for the UNAI GPU renderer to use inaccurate integer division for performance reasons, and the third is a platform-specific macro to toggle other features in the codebase. In this case it should be _MIYOO and the preprocessor checks in the C code should check for that instead of _miyoo which isn't defined anywhere.
The profile generation section in the Makefile is unnecessary as the RetroArch CI can't do anything with that. Some of the optimisation flags are unnecessary, -ffast-math is already included in -Ofast (plus some subsystems already specify the former), I got a warning about GPUopen with -flto, and it's not clear if -fdatasections and -ffunction-sections help. Also I think PIC should be specified to be consistent with the other cores.
I'll see if I have time this weekend to test with the different optimisation flags.

[Apaczer]

The Makefile indeed was unnecessary step, there were some optimization issues at first in TRIMUI so it was decided to put pcsx_rearmed as standalone emu from libretro source - only later it was moved to picoarch frontend as separate core.
On the side note, some binaries from Miyoo work as well on Trimui without recompiling them and to fix some of buttons input mismatches the dev team decived to add option in Gmenux to reassigment them separetly by user's wish.

[jSTE0]

Submitted as libretro/pcsx_rearmed#629. I've opted to make minimal changes to the build flags, sticking closely to the Wiz/Caanoo build flags as they have the same CPU. -ffast-math is already enabled for all platforms, -O3 generates a binary that's 11% larger while -Ofast is 10.7% larger compared to the default -O2 and this platform doesn't have L2 cache.
I've left the CPU at the default 50% clock for pre-ARMv7 platforms as that's what the standalone emulator uses. Similarly, I've left the SPU options at the default for pre-ARMv7 platforms meaning reverb and interpolation disabled. Ditto for dithering.

[jSTE0]

alsa audio driver indeed enables Frameskip options across these cores, however I see almost double performance loss with that audio output compering to default sdl.

I seem to have a different experience, on other cores without frameskip I get fewer audio underruns. Could you quantify the performance loss, what is the change in fps?
SDL audio actually uses ALSA as its backend (it has to use something provided by the host OS) so to my mind using ALSA in RetroArch basically bypasses SDL acting as middleware.

Would that be possible to have sdl audio working with neonloop's frame skip implementations?

That would require the SDL audio driver to implement sdl_audio_write_avail() correctly, i.e. report its actual buffer status instead of 0, and also implement sdl_audio_buffer_size(). I don't know enough about SDL, or audio buffering, to implement that.

[Apaczer]

I seem to have a different experience, on other cores without frameskip I get fewer audio underruns. Could you quantify the performance loss, what is the change in fps

Please be sure set audio driver before launching content and double check while in game if that audio output is there (no overrides are enabled). I see almost aprox. 20fps drop across board, no deny about that.

UPDATE: Upon futher inspection seems that setting recommended 22kHZ audio rate for sdl intruduced unexpected fps drop with alsa. Changing back to default 32kHZ reversed above drawback.

Surely that is great improvement with working frameskip! We will have to update wiki's info to have default audio rate and "alsa" enabled for frameskip to work as intended (when you PR will be ready).

[jSTE0]

Ah, that explains it, I had the sample rate set to 32000Hz, which is the closest to the SNES 32040Hz. The default 32730Hz was originally for the 3DS, it's related to its refresh rate, and for some reason the RetroFW adopted it as well and, in turn, Miyoo. Perhaps that should be changed.

[neonloop]

Thanks! That breaks the CI build for Miyoo though

That is my mistake, Maybe I am doing too many things at the same time 😃 Thanks for fixing it!

[jSTE0]

@neonloop No worries, thanks for contributing your frameskip implementation and sharing your experience, it's helped to improve the Miyoo port of RetroArch.

[Apaczer]

Compiled and tested latest commit for pcsx_rearmed (TKS for PR!), however the frameskipping is not working from my end (even setting fixed_interval now makes render every frame on Miyoo - thus slowing down frame pacing). I've had noticed similar problem on MAME-2000, where I did not see difference between OFF and AUTO options, but it might that it works nevertheless here regardless of selected option (I see no v.image slowdown but only hear occasional audio stuttering on more demanding titles).

Tests performed with:

• PSX (libretro/pcsx_rearmed@e4072f7)
  [USA] Crash Bandicoot
  [USA] Castelvania Chronicles

• MAME-2000 (libretro/mame2000-libretro@098df85)
  The Punisher
  Ghouls'n Ghosts

[neonloop]

That is disappointing, on pcsx_rearmed if you select "Fixed Interval," and Frameskip Interval to 10, does it drop most frames?

For pcsx_rearmed and mame frameskip, Frameskip Interval must be set to maximum number of frames to skip before forcing a frame to be rendered. Some cores hardcode to 30, but that was too choppy for trimui when skipping frame wasn't fast enough, so Frameskip Interval sets maximum for all frameskip types.

Crash Bandicoot still has audio stuttering on trimui -- frameskip helps, but I think it is still too slow to be enjoyable. With frameskip auto and interval 4, Castlevania Chronicles video stutters in first hallway on trimui, but audio is smoother.

[Apaczer]

Yes, sorry I couldn't invoke frameskip in any of these variations in pcsx core. Image is being forced to render every frame, whatever I try and slows pacing of video/audio rendering (very prominent on Crash Bandicoot).

Testing from my arm64 phone shows that fixed_frameskip works in latest build (but it is more powerful platform and I couldn't test auto properly). Maybe there is something in Miyoo target that could be fixed, as Trimui show somewhat possitve results?

[jSTE0]

ALSA audio driver for Miyoo has been submitted as libretro/RetroArch#13814.