lr-fbalpha now fast on PiZero & rpi1

barbudreadmon

You can now build lr-fbalpha with an optional USE_CYCLONE=1 argument, it'll replace the normal m68k interpreter "musashi" with the m68k arm dynarec "cyclone" when possible, allowing better performances for games relying on a m68k cpu (which probably means half of the fbalpha library, including cps1, cps2 and neogeo) for slow arm devices like the PiZero & Pi1. Afaik this dynarec is the reason why pifba is running ok on those devices, so most likely you won't need pifba anymore if you use this.
I tested it on a downclocked rpi3 (at the stock frequency of the Pi1, which is 700Mhz) on a few cps2 games, they ran at full speed while using only 60% of 1 core. Any feedback welcome.

Be aware that you won't be able to use your pifba romset with current lr-fbalpha, pifba romset is almost 10 years old

nasp2000

This info is so good... i will try soon...

Darksavior

@barbudreadmon Where do I put that argument?

mitu

@Darksavior If you modify the scriptmodule to re-build from source, it should be somewhere around here - notice how HAVE_NEON option is added. Note that if you compile on a Pi 0/1, you'll have to pick the other branch of the if, for non-NEON enabled systems.

BuZz

I will enable the option for armv6 devices for now. [edit] this is done and rpi1 binaries are updated.

@barbudreadmon the rpi3 running at 700Mhz will still be a fair amount faster than the rpi0/1 I think. I will try it out on a rpi1 system. Thanks for the improvements.

Darksavior

Nevermind, not sure if the argument is enabled. Had to try an older build to compare and didn't notice

barbudreadmon

@Darksavior said in lr-fbalpha now fast on PiZero & rpi1:

Excellent. This helps on the pi3b/b+ as well.

I don't recommend using it on arch besides rpi0/1 for several reasons :

savestates from cyclone aren't compatible with savestates from musashi
for the reason above, it's also breaking netplay cross-platform compatibility
i can't really say for sure that this cyclone implementation is bug free
at the very least i think it breaks support for megadrive games (if you are using fbalpha for megadrive)

Darksavior

@barbudreadmon Yea I just noticed it breaks system18.

barbudreadmon

@BuZz now i build cyclone support for all arm platform, however you have to enable it through the core options (disabled by default, for the reasons explained above).

@Darksavior i guess it solves the issue with system18 since you'll be able to use core option overrides.

BuZz

@barbudreadmon Thanks. Enabled for all arm platforms. Binaries have also been updated now.

lostless

i just tried the cyclone support on a pi zero and did not notice any improvements. All i tested was some neo geo games though. Am I missing something?

Darksavior

@lostless Enable Cyclone from Rgui: Quick Menu, Options.

BuZz

Just to note, I did actually update Jessie packages too. But this may be the last time. (I have to build everything 4 times currently and I want people to update to Stretch)

lostless

@Darksavior did that, seem to make no difference.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

@Darksavior did that, seem to make no difference.

You need to restart the core (most likely close and reopen actually).

Edit : my bad, i confirm i messed up when reworking this as a core option, cyclone is always disabled, should be fixed in my next commit.
Edit 2 : Should work as expected now, also improved description of the core option...

lostless

@barbudreadmon after spending 5 hours compiling on a pi zero, Lol, there still is no difference.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

there still is no difference.

Having no difference at all doesn't make any sense, at the very least it is using ~30% less cpu with cyclone enabled. I tried downclocking my rpi3 again (this time to 600Mhz), i played Street Fighter Alpha 3 which is probably one of the most demanding m68k games :

with cyclone enabled, max cpu usage was 80% (happened once around the end of the attract mode) with a minimum around 50%.
with musashi, cpu couldn't handle it, minimum was 80%, regular spikes above 100%, causing slowdowns

Let's confirm your issue is not elsewhere :

what's the commit you are using (next to the emulator version in bottom left of rgui) ?
do you have something that could cause heavy cpu usage ? like rewind or advanced shaders ?
did you shutdown the emulator after enabling cyclone ? not just "restart" in the ui ?

Also, you don't need to spend 5 hours building this, downloading the armhf version at libretro buildbot and replacing yours should be fine : http://buildbot.libretro.com/nightly/linux/armhf/latest/fbalpha_libretro.so.zip

lostless

@barbudreadmon Im using build cb4826a. I guess some games speed up better then others. I tested neo geo and was a tad faster. Games like simpsons arcade I noticed no change. But its still not full speed on a pi zero. But was fun to test out.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

@barbudreadmon Im using build cb4826a. I guess some games speed up better then others. I tested neo geo and was a tad faster. Games like simpsons arcade I noticed no change. But its still not full speed on a pi zero. But was fun to test out.

I explained it was only affecting games using the m68k cpu, simpsons is not one of them.
Could you try using a frameskip of 1 in core options for neogeo ? To see if the bottleneck is the rendering.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

Im using build cb4826a

What the fuck with that commit actually ? It doesn't even exist in https://github.com/libretro/fbalpha/commits/master, seems to me like you are not even using the right emulator...