Home Page Forums MAME Non-Windows MAME Support Arm Akimbo SDLMAME

If the SDK's in a VM without accelerated video that's probably to be expected. Run in a window and shrink the window so it's exactly the size of the game to remove scaling from the equation and you should get the actual performance. In the case of the x86 VM I'd expect it to be probably 20-30% slower than native in that instance. Making the window bigger or running full-screen in the VM will degrade performance substantially.

ETA: I should mention that the Pandora's slipped to January now (*sigh*) so that limits my ability to do much towards this at the moment.

I'm definitely not expecting the Pandora to be out before i want to have this on the N900 in working condition. Also, there's only so much i can do to test performance without putting it on the N900 and seeing how it runs. I am expecting mine by the end of the month. The rule of thumb on the #maemo channel is that most things that work on N900, don't in SDK, so as you can imagine, it's not a great way to predict performance.

So what i'd like to know is what bits of code that are optimized asm for x86 would most greatly benefit by having armel asm instead of C, and work on that. Unless there's another obvious optimization you are aware of...

The general assembly helpers used by the actual emulation are all in src/emu/eigccx86.h (x86 and x64) and eigccppc.h (PowerPC). There's math, I think some endian-swap helpers, and thread-sync primitives. Having an ARM version of that file is the first necessary step.

There's some more sophisticated assembly in src/osd/sdl/sdlsync_ntc.c, but that should only be needed if you have multiple CPUs. But speaking of this, why is sdlsync_tc.c used on Linux and generic UINX? I would have thought sdlsync_ntc.c should still give better performance.

You won't get much out of a chip with such small L1 (16KB + 16 KB) and L2 (256KB) caches running MAME.

Your best bet is probably to optimize the CPU cores, where optimize means use some existing ARM assembly core (but beware of those, they probably aren't very accurate).

The next step probably is to write a new DRC back-end.

(All of that should only be done once you'll have profiled SDLMAME on the real target of course.)

My N900 is supposed to be delivered around Christmas, so i'll be able to try it out and see what/how it works. Is there a WIP version of sdlmame being released soon? If not i'll make a package of this one to have available when i'm away from my dev box.

Re: profiling--is there a mame-specific way to do this?

Various standard profilers have been used successfully on MAME including Valgrind and gprof.

Sorry valgrind can't be trusted... especially as it won't run on ARM

oprofile is pretty good, but I don't know how well it runs on Cortex-A8 (especially given that there are CPU errata affecting performance counters).

I thought the point of ARM was that the core's so simple there can't be errata ;-)

Nah, the point of ARM is to replace Intel, so they have to keep the number of errata high enough