Odroid XU4 MAME Performance?

barbudreadmon

@loggahead Actually the issue is not with the rpi3 struggling. I think i figured the fix, just waiting for upstream advice before committing it since i'm worried about potential side effects. If everything goes well, it will be available later today.

@dankcushions @mediamogul :
As a side note, i'm not sure how retropie handle cflags for lr-fbalpha (the installation script at https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-fbalpha.sh seems really outdated, profile has been deprecated 2 or 3 years ago and platform will generally handle the right cflags if set with the appropriate value), but i noticed this game performs a lot better on my rpi3 when "--ffast-math" is enabled, probably because the driver uses a lot of arythmetics.

mitu

@barbudreadmon What would your recommend to change for the build step in the package ? Some optimization flags could be added via CFLAGS/CPPFLAGS, like the --fast-math directive.

barbudreadmon

@mitu replacing build_lr-fbalpha by something like this would probably be ok :

function build_lr-fbalpha() {
make -f makefile.libretro clean
local params=()
if isPlatform "rpi2"; then
params+=("platform=rpi2")
elif isPlatform "rpi3"; then
params+=("platform=rpi3")
fi
make -f makefile.libretro "${params[@]}"
md_ret_require="$md_build/fbalpha_libretro.so"
}

If you got something to detect if the platform is x86 and 32 bits, you could probably also add the FASTCALL=1 parameter

mitu

@barbudreadmon The RetroPie script already has some CFLAGS set by platform when compiling. For the PI3 they are

-O2 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -pipe

When running the compile with make -f makefile.libretro platform=rpi3 (and disabling the RP script CFLAGS), the flags added by the build detection are

 -O3 -marm -mcpu=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffast-math

They're more or less equivalent in terms of cpu/arch specifications, what's missing is the -ffast-math and the FASTCALL for the x86 arch. For reference, these are set here.

barbudreadmon

@mitu iirc, -ffast-math includes -funsafe-math-optimizations, -O3 includes -ftree-vectorize, also -O3 will be included whatever you do when building lr-fbalpha, i think it's safe to build with both -O2 and -O3 (the later should override the first) but i'm not 100% sure.
-march=armv8-a+crc -mtune=cortex-a53 is the recommended setting for rpi3 in 64bits mode, i'm not sure what happens with performance when you use it in 32bits mode. With gcc-6.x i know you can also use -march=native in 64bits mode.

barbudreadmon

@loggahead btw, the fix was commited yesterday, now raiden2 runs flawlessly with lr-fbalpha on arm devices. You'll probably need to update from source to see those changes.

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

now raiden2 runs flawlessly with lr-fbalpha on arm devices

YES !!! You and all involved ROCK !!! Thanks so much!!!

I just have to update the lr-fbalpha package right? I also plan to re-image and upgrade to 4.4 this weekend, I take it after I upgrade, I'll need to update fba again?

barbudreadmon

@loggahead said in Odroid XU4 MAME Performance?:

I just have to update the lr-fbalpha package right?

If you mean from binary, probably not. As said above you'll probably have to update from sources.

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

As said above you'll probably have to update from sources.

K. Ill give it a shot tonight! Thanks again!

Loggahead

@barbudreadmon said in Odroid XU4 MAME Performance?:

@loggahead said in Odroid XU4 MAME Performance?:

I just have to update the lr-fbalpha package right?

If you mean from binary, probably not. As said above you'll probably have to update from sources.

This worked! Thanks so much again!