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.
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.
