GP2X Gp2x Speed Benchmarking


jbb

Still Fresh
Joined
May 28, 2003
Messages
63
Hi all,

I keep having speed "weirdness", trying to convert my various games from the GP32 (that were running fs0 at 133Mhz) to SDL onto GP2x.
Basically with exactly the same C code (compiled with gcc4 -O2, on MacOSX), but with obviously gfx routines using SDL functions, I keep hitting disappointing framerates - 50% slower at least, and that's without sound. I must admit I was kind of expecting to fly twice as fast instead... Mmmm. :(

- Has anyone else tried to convert their GP32 proggies, and compared framerates?
- Has anyone tried to benchmark properly the GP2x? Against a GP32 @ 66, 133 or 166Mhz? Or the Zodiac, or even some 200 Mhz PocketPCs?

...it would be interesting to compare experiences.
(I think I read Squidge hit similar problems porting the Amiga emulator)

I know it's all a bit early, and I apologise for ranting... I'm sure it will improve with time... But right now, having to overclock my Gp2x to 250Mhz (draining 2500ma batteries every 3h), just to crawl back up to Gp32 territory framerates is not what I had in mind when upgrading!

JBB
 

woogal

Certified Guru
Joined
May 15, 2003
Messages
1,823
Age
44
Location
Newark, UK
Website
gp32.sector808.org
The only thing I've really compared is Quake on the GP2X and the Zodiac. On the 2X the speed is very slightly higher than the Zodiac, but the Zodiac is scaling up from 320x240 to 480x320 (using hardware) so I'm guessing that is the main cause of the slight performance difference. I did try a quick test of clocking the 2X down to around the same speed as the gp32 and from what I remember the speeds seemed similar, but I've not done any accurate tests on that yet. Duke clocked down to 133mhz feels kind of the same as on the gp32, but that's hardly an accurate test either.

I have ported one other app from the gp32 to the gp2x, but I don't know how the speed compares because I've not tried clocking the 2x down to the same speed as the gp32 version yet (I'll try that as soon as I can and let you know the result).
 

Radek

Certified Guru
Joined
Oct 13, 2005
Messages
871
jbb posted on Dec 27 2005 at 01:04 AM said:
Hi all at

I keep having speed "weirdness", trying to convert my various games from the GP32 (that were running fs0 at 133Mhz) to SDL onto GP2x.
Basically with exactly the same C code (compiled with gcc4 -O2, on MacOSX), but with obviously gfx routines using SDL functions, I keep hitting disappointing framerates - 50% slower at least, and that's without sound. I must admit I was kind of expecting to fly twice as fast instead... Mmmm. :(

Cpu wise the gp2x has exactly more power as its more available cpu's cycles allows. Your dissapointing perfomance is probably due to not optimal implementation of SDL in the gp2x's firmware. For now not only it isn't using any hardware capabilites of MMSP2 chipset but isn't as tuned as in the gp32 either.

This is all imho of course.
 
Last edited by a moderator:

gfoot

Member
Joined
Nov 15, 2005
Messages
218
Any time something is slow, but especially when you don't expect it, you really need to figure out what aspect of it is slow. e.g. is it your graphics that's slow? are you running in 16 bit mode or 8 bit mode? (is that the same as on the gp32?) is SDL doing a dynamic conversion because your graphics are in the wrong format? I doubt pure CPU benchmarking would reveal anything unexpected, unless your process isn't getting 100% of the CPU due to background processes (hope not!).

It looks like gprof is implemented in devkitGP2X, so maybe you can also do a profiling build and get some hard numbers out to see if anything in particular is running slow. Dunno if you can do the same on the gp32 though - I never had one of those!
 

jbb

Still Fresh
Joined
May 28, 2003
Messages
63
SDL is partially at fault I'm sure. But I'm all in 8 bit mode (screen and sprites), all sharing the same palette... pretty straightforward, and yes: exactly the same as the GP32.

I now replaced all the SDL_blit functions with SDL_surface_locks, followed by direct surface byte by byte "poking". So it is not very much like on Gp32... and SDL is now really thin: only there initialising the screen, and handling the surfaces/bmp frameworks.

Good news : it is indeed significantly faster, but... Bad news : it is still a little slower than the Gp32 version @ 133mhz, and still without sound. :(

Puzzling really. I'll try profiling further with the two machines next to each other.
JBB
 
Top