Retroarch cores now made usable by Pi 2?

[cacophony555]

I'm curious what retroarch cores have now become usable with the extra processing power of the Pi 2. Also, any hints on how to build them in a more optimized fashion would be appreciated.

I just tried building/running two SNES cores on my Pi 2:
(for both of them I just did a "make" with no arguments or changes to the Makefile)

snes9x-next (based on SNES9x 1.52+)
https://github.com/libretro/snes9x-next

bsnes-mercury
https://github.com/libretro/bsnes-mercury

My quick test makes me wonder if retroarch's snes9x-next is now the best snes emulator for the Pi 2. It seemed like it was running at full speed and it's the only snes emulator thus far to pass my sound test (intro part to Final Fantasy 3 music plays at full speed and the part with wind noise sounds like actual wind!).

bsnes-mercury was unusably slow (kind of expected) but perhaps I didn't build it with the correct options.

What other cores should I be trying?

[steev]

Genesis Plus GX is full speed now. Probably one of the most accurate Genesis/Megadrive/CD emulators around.

PCSX ReARMed now runs most games at full speed. Since the Pi 2 has an ARMv7 processor, it can use Exophase's NEON GPU plugin, which is very accurate and fast. It can also render games at higher resolutions (though that is a little slow on the Pi 2)

32X games run much better in Picodrive now

Desmume is still pretty slow, though I found at least one game that was rather playable (Tetris DS, ~40fps)

I cross-compile most of the cores on my Linux PC using the toolchain from https://github.com/raspberrypi/tools.git

I have this little script I source before I compile something:

Code: Select all

export CC_PREFIX="/home/steven/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64"
export CROSS_COMPILE="${CC_PREFIX}/bin/arm-linux-gnueabihf-"
# Due to compiler bug in gcc 4.8, use this toolchain to compile Desmume:
#export CROSS_COMPILE="/home/steven/pi/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/arm-bcm2708hardfp-linux-gnueabi-"
export CC="${CROSS_COMPILE}gcc"
export CXX="${CROSS_COMPILE}g++"
export AS="${CROSS_COMPILE}as"
export AR="${CROSS_COMPILE}ar"
export CFLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -I${CC_PREFIX}/include -I${CC_PREFIX}/opt/vc/include -I${CC_PREFIX}/opt/vc/include/interface/vmcs_host/linux -I${CC_PREFIX}/opt/vc/include/interface/vcos/pthreads"
export CXXFLAGS="$CFLAGS"
export ASFLAGS="$CFLAGS"
export LDFLAGS="-L${CC_PREFIX}/lib -L${CC_PREFIX}/opt/vc/lib"

Then to compile most cores I use:

Code: Select all

$ . ~/pidev.sh
$ make -f Makefile.libretro platform="armv neon hardfloat" -j4

But some are a little different, so you'll have to look at the Makefile

[cacophony555]

Thanks steev.

Is there any advantage to cross compiling in this case other than to speed up the compilation/linking process itself? I'd prefer to just build on the Pi if possible, but I also want to ensure that what's built is optimal.

So hoping I can just do this to build on the pi (for example in the case of pcsx_rearmed):

Code: Select all

make -f Makefile.libretro platform="armv neon hardfloat" -j4

Though I'm wondering if I should be modifying the Makefile.libretro to specify the mcpu b/c as written it appears neither case applies and mcpu will not be set at all:

Code: Select all

ifneq (,$(findstring cortexa8,$(platform)))
   CFLAGS += -marm -mcpu=cortex-a8
   ASFLAGS += -mcpu=cortex-a8
else ifneq (,$(findstring cortexa9,$(platform)))
   CFLAGS += -marm -mcpu=cortex-a9
   ASFLAGS += -mcpu=cortex-a9
endif

Or perhaps I should just set these before running make on the pi?

Code: Select all

export CFLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"
export CXXFLAGS="$CFLAGS"
export ASFLAGS="$CFLAGS"

I'm also curious what options you'd suggest for building retroarch itself. There's an old tutorial on this below, but it was written for the original Pi:
http://www.raspberrypi.org/forums/viewt ... 78&t=56070
and suggests the following:

Code: Select all

CFLAGS="-Ofast -march=armv6j -mfpu=vfp -mfloat-abi=hard" ./configure --disable-x11 --enable-floathard --disable-ffmpeg --disable-netplay --enable-udev --disable-sdl --disable-pulse --disable-oss

Based on your suggestions above mfpu should change to neon-vfpv4. But not sure whether it makes sense to use mcpu instead of march, or if the other listed options still make sense.
Edit: Ah, I see there are already some updated suggestions for retroarch building in the thread: http://www.raspberrypi.org/forums/viewt ... 72#p686472

[Neil Munday]

Hi,

If it helps here are all the scripts I use for compiling RetroArch and the various cores used by PES for the Raspberry Pi 2: https://github.com/neilmunday/pes/tree/ ... /arch-rpi2

Note that I am using my own compilation of SDL2 rather than the one provided by ArchLinux.

Hope this helps,

Neil.

[Vanfanel]

SDL2 is NOT needed for libretro/RetroArch on the Pi/Pi2 and thus should be avoided.
VG/GLES for video, ALSA for audio, and Udev for input. SDL2 is not needed at all.

[Neil Munday]

SDL2 is NOT needed for libretro/RetroArch on the Pi/Pi2 and thus should be avoided.

Indeed, it would appear it was left in my build scripts after doing some joystick testing debugging to get to the bottom of an issue with the linuxraw driver, see: https://github.com/libretro/RetroArch/issues/1296

I have re-tested by build without SDL and it works fine. I wasn't using SDL anyway for graphics, sound or input - it was just included for experimentation. My SDL2 build was also linked against the GLES libraries rather than Mesa (as the ArchLinux version does).

I have therefore updated my build scripts as necessary.

Cheers,

Neil.

[cacophony555]

Hey Neil, out of curiosity, why are you using pocketsnes instead of snes9x-next?

BTW, thanks for linking to your scripts. I see you passed --enable-neon to the configure of retroarch, so that's a good tip.

[Neil Munday]

Hey Neil, out of curiosity, why are you using pocketsnes instead of snes9x-next?

pocketsnes is based on an earlier version of snes9x (1.43-dev I believe). In my experience it seems to perform better on more games than snes9x-next on the Raspberry Pi at least. I haven't tried snes9x-next on my Raspberry Pi 2 yet, but I would be interested to know if you find it performs better.

Cheers,

Neil.

[cacophony555]

A couple differences I noticed between the PES retroarch build parameters and what was suggested by Vanfanel:

PES is set to disable-udev and doesn't specify anything for oss, while Vanfanel's instructions say to enable-udev and disable-oss.

Any reason behind these differences?

[steev]

Thanks steev.

Is there any advantage to cross compiling in this case other than to speed up the compilation/linking process itself? I'd prefer to just build on the Pi if possible, but I also want to ensure that what's built is optimal.

No, cross-compiling is just to speed up the build process.

Though I'm wondering if I should be modifying the Makefile.libretro to specify the mcpu b/c as written it appears neither case applies and mcpu will not be set at all:

Code: Select all

ifneq (,$(findstring cortexa8,$(platform)))
   CFLAGS += -marm -mcpu=cortex-a8
   ASFLAGS += -mcpu=cortex-a8
else ifneq (,$(findstring cortexa9,$(platform)))
   CFLAGS += -marm -mcpu=cortex-a9
   ASFLAGS += -mcpu=cortex-a9
endif

Or perhaps I should just set these before running make on the pi?

Code: Select all

export CFLAGS="-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"
export CXXFLAGS="$CFLAGS"
export ASFLAGS="$CFLAGS"

Either way should work

[steev]

A couple differences I noticed between the PES retroarch build parameters and what was suggested by Vanfanel:

PES is set to disable-udev and doesn't specify anything for oss, while Vanfanel's instructions say to enable-udev and disable-oss.

Any reason behind these differences?

The udev input driver is nicer because it gives you controller vibration support, supports hotplugging, and doesn't complain if you start retroarch from an ssh session.
I believe it is recommended over linuxraw or SDL

OSS - You don't need it for the Pi 2, so you can disable it to get a smaller build, but either way it shouldn't affect performance (retroarch will prefer the alsathread driver on the Pi 2)

[Neil Munday]

As steev said, RetroArch uses ALSA by default. Without the "--disable/enable-oss" option RetroArch will compile support for it if found on your system.

In regards to why PES does not compile RetroArch with udev support, this is due to an issue I found with udev/SDL 1.2. It's quite an odd one. PES uses PyGame to create its GUI which is built on top of SDL 1.2. With udev/edev enabled and with multiple control pads from different manufacturers, the joystick enumeration presented to PyGAME via SDL gets messed up. For full details: see http://forums.libsdl.org/viewtopic.php?t=10813 This is very much due to me using PyGame - you should be fine compiling RetroArch with udev support.

Cheers,

Neil.

[cacophony555]

Thanks for all the helpful replies!

Anyone have an opinion on using -Ofast vs -O3 vs O2 when building? I'm inclined to go with -Ofast.