GP2X Optimization/profiling Help


charlieb

Member
Joined
Nov 30, 2006
Messages
116
So I have all the graphics features I want in place for my wireframe so now it's time to think about optimization. I compiled my program with -pg to generate profiling data and ran it on the pc and the gp2x. The results were a bit of a suprise to me: on the pc the most time is spent in the matrix calculations, actually applying the the matrices to the points which is what you would expect since there are an order of magnitude more of those than any other calculation. On the gp2x most of the time seems to be spent in the pixel drawing function with a lesser percentage spent in the actual matrix calculations.
Here are the first few lines of each output:

PC:
CODE

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
39.14 5.17 5.17 13768944 0.00 0.00 apply_mp
26.65 8.69 3.52 1727343 0.00 0.00 apply_mm
15.67 10.76 2.07 __divdi3
7.57 11.76 1.00 286653 0.00 0.00 draw_frame_fade_z
5.00 12.42 0.66 1 0.66 11.00 run_level_performance_test
3.48 12.88 0.46 6879672 0.00 0.00 apply_w
1.29 13.05 0.17 286653 0.00 0.00 advance_sprite
0.76 13.15 0.10 menu
0.15 13.17 0.02 303692 0.00 0.00 id
0.15 13.19 0.02 5379 0.00 0.00 draw_crosshair



GP2X:
CODE

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
25.30 58.09 58.09 _putPixelAlpha
9.37 79.60 21.52 _filledRectAlpha
8.96 100.17 20.57 GP2X_FlipHWSurface
8.37 119.38 19.21 aalineColorInt
7.27 136.08 16.70 __udivsi3
6.82 151.74 15.66 SDL_MapRGBA
6.55 166.78 15.04 __umodsi3
5.25 178.84 12.06 4854144 0.00 0.00 apply_mp
5.09 190.52 11.68 __divdi3
2.81 196.97 6.45 612993 0.00 0.00 apply_mm
2.38 202.43 5.46 mcount_internal
1.60 206.10 3.67 100928 0.00 0.00 draw_frame_fade_z
1.35 209.19 3.09 1 3.09 28.47 run_level_performance_test
1.28 212.13 2.94 GP2X_LockHWSurface
1.09 214.64 2.51 2422272 0.00 0.00 apply_w
0.66 216.15 1.52 clipLine
0.39 217.04 0.89 pthread_mutex_lock
0.37 217.90 0.86 __divsi3
0.30 218.59 0.69 __slowexp
0.28 219.24 0.65 SDL_LockSurface
0.27 219.87 0.63 100928 0.00 0.00 advance_sprite



Is the difference here just to do with the fact that the GP2X version is compiled statically so the results are pretty much the same except that I don't see dynamically loaded symbols in the PC version?
Are the GP2X pixel drawing functions inherently slower (in proportion) than the PC's?
And the most important question: will I get a worthwhile performance boost from optimizing the matrix calculations including reducing the number of calls to apply_mp (apply matrix to point).

At the moment I'm only getting to draw about 80 lines at 60fps (or 90 without anti-aliasing) which isn't really enough for targets and backgrounds :( . I think I can reduce the number of calls to apply_mp by about 2/3 for undestroyed sprites and I know that there I can use some special techniques to avoid processing the zero elements of the matrices in general but if it's not going to make a significant difference to the number of lines I can use I should spend the time generating content for the with the limited number of lines I can draw instead.

Thanks
Charlie

P.S. I just wanted to add that my question about pixel drawing functions being slower on the gp2x is certainly not a criticism of the excellent sdl and sdl_gfx libraries. I couldn't have done *any* of this stuff without them.
 
You can speed up pixel drawing by writing your own getpixel() and putpixel() functions. Make them so that they don't lock the surface and then manually lock it before all the getpixel() and putpixel() operations and unlock it afterwards. That way you could save a lot of locks. You can also do optimized versions for certain color depths and without checking boundaries (dangerous).

Don't know if that makes sense to you.
 
Simon Parzer said:
You can speed up pixel drawing by writing your own getpixel() and putpixel() functions. Make them so that they don't lock the surface and then manually lock it before all the getpixel() and putpixel() operations and unlock it afterwards. That way you could save a lot of locks.
That does make sense, I'll have to check the SDL_gfx sources to see if they're alreay doing it but if not it sounds like that could make quite a big difference.

Squidge said:
If your constantly writing to the frame buffer, MMU hack may help?
Does SDL constantly write to the frame buffer? Excuse my ignorance but this is the closest I've been to the silicon, well, ever.

I did also run some pure line drawing benchmarks and I found that gp2x+SDL_gfx can draw ~400 lines/frame @ 60 fps so clearly I've got some way to go before I can approach that and start complaining that the line drawing algorithms aren't fast enough.

Cheers,
Charlie
 
Last edited by a moderator:
charlieb said:
...
Does SDL constantly write to the frame buffer? Excuse my ignorance but this is the closest I've been to the silicon, well, ever.

I did also run some pure line drawing benchmarks and I found that gp2x+SDL_gfx can draw ~400 lines/frame @ 60 fps so clearly I've got some way to go before I can approach that and start complaining that the line drawing algorithms aren't fast enough.

Cheers,
Charlie
If you use ALPHA, MMUHACK will increase a lot your speed !
;)
If you want to see an alpha speed boost example with mmuhack you can test drill2x xtreme with and without mmuhack module and you will see the big difference in alpha fadein & alpha fadeout
:)
 
Last edited by a moderator:
Sorry for beeing a bit offtopic, but how did you do a profiling on the gp2x - just added a -pg for the project during compile ? Are you able to use optimization-flags for the profiling build ?
For me it isn't working at all on the gp2x - it just segfaults or doesn't generate any data in the output file.
On my PC profiling is working without a problem.
 
QUOTE
Sorry for beeing a bit offtopic, but how did you do a profiling on the gp2x - just added a -pg for the project during compile ? Are you able to use optimization-flags for the profiling build ?
For me it isn't working at all on the gp2x - it just segfaults or doesn't generate any data in the output file.


If you do execl() at the end (in order to run the gp2xmenu) your profiling-enabled program will crash.
 
scachi, there is a post on these forums by Notaz I believe explaining how exactly to get gcc to generate decent profiling data.
 
Squidge said:
scachi, there is a post on these forums by Notaz I believe explaining how exactly to get gcc to generate decent profiling data.
Thank you very much, I have found it.
 
Last edited by a moderator:
Squidge said:
scachi, there is a post on these forums by Notaz I believe explaining how exactly to get gcc to generate decent profiling data.
Yup, that's how I did it (and knew how to)

C
 
Last edited by a moderator:
Squidge said:
scachi, there is a post on these forums by Notaz I believe explaining how exactly to get gcc to generate decent profiling data.
Any chance of a link? I will search, but it's easier if someone already knows where it is. I want to bug-fix CromoZome and then optimise some more ^^
 
Last edited by a moderator:
PokeParadox said:
Squidge said:
scachi, there is a post on these forums by Notaz I believe explaining how exactly to get gcc to generate decent profiling data.
Any chance of a link? I will search, but it's easier if someone already knows where it is. I want to bug-fix CromoZome and then optimise some more ^^

It's actually pinned on the Developers' Corner [GP2X] board but here it is in full linky glory
http://www.gp32x.de/board/index.php?showtopic=28490
The second page also has some great information:
http://www.gp32x.de/board/index.php?showt...28490&st=15
 
Last edited by a moderator:
Back
Top