View Single Post
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#5
Originally Posted by sbock View Post
Flandry, what do you think about adding some ARM optimizations from MAME4all (e.g. Cylone and Dr80 CPU cores)?
The source is available here: http://www.talfi.net/gp32_franxis/
I have added my quote about my philosophy and plans for SDLMAME from the emulators thread to the first post here. Short answer to your question: probably not, unless it turns out that the goals are unattainable otherwise. I want to track the upstream source as much as is possible, diverging only for customizations necessary for Maemo.

Here are a couple relevant posts about optimizing MAME from the emulators thread.

Originally Posted by Flandry View Post
GL ES support is not as easy as flipping a switch and it's not something i'm going to look into until it's clear it's the best way to get where i want MAME to be. There is no 3D rendering going on in MAME--it's all emulated--and from the few conversations on drawing performance i was privy to, the memory bandwidth of the device is often the limiting factor for graphics-intensive apps. I hope someone who knows the details better can pitch in with better knowledge, but my understanding is that without independent RAM of its own to use, bringing in the GPU for drawing can actually reduce performance because of extra transfers to/from RAM. Whether that's actually the case or not, the limitations of the N900 hardware compared to a PC are such that i'm not at all sure that GL ES is going to be worth the effort. I haven't done any detailed profiling yet since the update.

Regarding the question of how much the PR1.1 system updates influence SDLMAME performance, here's what i found (using just a single older ROM):

No hardware scaling: 34% -> 52%
YUV overlay: 86% -> 88%

Which is kinda what i expected as mentioned earlier.

One interesting thing is that the kernel is now more occupied during execution than the mame binary is, in either case. I'm not sure what that means, but it suggests that the actual emulation is still the minor part of the cycle usage.
Originally Posted by Flandry View Post
Still not ready to take feature requests, but i have profiled the program again and the drawing and YUV translation functins are the holdups, so i am faced with coding optimized assembler routines or implementing GL ES to pursue any significant speedup. Before doing that i will probably do more thorough testing and tweak the keymaps and other control setups to see how the current codebase compares with my expectations. As has been noticed, much of the UI is still unaltered from upstream, which is intended for PCs wih full keyboards.

Community todo #3
A summary of which controls are actually important and which keys should be mapped to what is still welcome as i mentioned a while ago. Time spent messing with keymaps could probably better be spent on development.
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful

Last edited by Flandry; 2010-01-31 at 21:55.
 

The Following User Says Thank You to Flandry For This Useful Post: