GP2X Sdl_gfx Performance Testing

[charlieb]

I have been doing a little performance testing of the SDL_gfx anti-aliased line drawing function and I'm getting some strange (I think) results. The program I used to test just draws incresing numbers of vertical lines on the screen. The results show some really strange jumps that I am at a loss to explain. I tried applying the mmuhack which improved matters a little but the jumps are still occurring. Can anyone explain them?

Here's a graph of the same program running for much longer:

The sources and compiled versions are here

 

[Trenki]

I didn't look at the sources but I suppose you should get a straight line in the graph. I suppose its a problem in your timing code! Maybe the timer you use does not have enough resolution.

 

[charlieb]

I didn't look at the sources but I suppose you should get a straight line in the graph. I suppose its a problem in your timing code! Maybe the timer you use does not have enough resolution.

I thought it might be something like that so I made a version that measures clock ticks instead of seconds ((float)(clock() - start) / (float)CLOCKS_PER_SEC)) and I got the same shape graph.
Then I actually eyeballed the data and I found something a little surprising:
CODE

50 frames : 610000 ticks : 20 lines : 81.967216 fps
50 frames : 620000 ticks : 40 lines : 80.645164 fps
50 frames : 610000 ticks : 60 lines : 81.967216 fps
50 frames : 620000 ticks : 80 lines : 80.645164 fps
50 frames : 610000 ticks : 100 lines : 81.967216 fps
50 frames : 610000 ticks : 120 lines : 81.967216 fps
50 frames : 610000 ticks : 140 lines : 81.967216 fps
50 frames : 610000 ticks : 160 lines : 81.967216 fps
50 frames : 630000 ticks : 180 lines : 79.365082 fps
50 frames : 630000 ticks : 200 lines : 79.365082 fps
50 frames : 670000 ticks : 220 lines : 74.626869 fps
50 frames : 1230000 ticks : 240 lines : 40.650406 fps
50 frames : 1230000 ticks : 260 lines : 40.650406 fps
50 frames : 1230000 ticks : 280 lines : 40.650406 fps



So it seems like the measurements are in 10,000 tick chunks which is weird but if we divide everything by 10,000 we still see that it is accurate enough since it noodles around the 600-650K mark then jumps to double that. What I'm saying is that if it can tell the difference between 610K and 630K then the difference between 600K and 1200K is still significant.

 

[sbseb88]

I thought it might be something like that so I made a version that measures clock ticks instead of seconds ((float)(clock() - start) / (float)CLOCKS_PER_SEC)) and I got the same shape graph.

Please ignore me if I'm wrong - but CLOCKS_PER_SEC is 1000 on the GP2X, right? So this still won't be any more precise, clock() still returns the time in milliseconds.

Reesy posted this some time ago. Simply #include <sys/time.h> into your project and use
CODE
struct timeval tval;
gettimeofday(&tval,0);
my_time = tval.tv_usec + 1000000 * tval.tv_sec;


This gives the time in microseconds. On the GP2X, I've checked the granularity and it seems to be okay - at least sub-millisecond. Hope this helps.

 

[charlieb]

Please ignore me if I'm wrong - but CLOCKS_PER_SEC is 1000 on the GP2X, right? So this still won't be any more precise, clock() still returns the time in milliseconds.

Thank-you but even with the millisecond timer the jumps in performance are still very significant. On the PC the graph is a relatively smooth curve of degrading performance. I'm more concerned with why the gp2x exhibits this behavoiur because it doesn't make any sense to me.

Mayb e there's a buffer that always takes the same amount of time to fill and 250 lines fill it and susequent lines have to be drawn in the next round but that's just baseless speculation.

 

[Creature XL]

I have been doing a little performance testing of the SDL_gfx anti-aliased line drawing function and I'm getting some strange (I think) results. The program I used to test just draws incresing numbers of vertical lines on the screen. The results show some really strange jumps that I am at a loss to explain. I tried applying the mmuhack which improved matters a little but the jumps are still occurring. Can anyone explain them?

You use HSSURFACE and DUOBLEBUF. As far as I had read, this combinationen uses wait for vsync. This would explain that at a certain point the time taken doubles. Try to disable vsync (maybe using SWSURFACE should do it. I am not so familiar with HW-SDL)
Or maybe you could try to implement tripple buffering, but I guess you need to doit by hand.

please keep me informed about your progress, cause I am interested in this to

edit: deleted images from quote.

 

[Dr_Ian]

You use HSSURFACE and DUOBLEBUF. As far as I had read, this combinationen uses wait for vsync. This would explain that at a certain point the time taken doubles. Try to disable vsync (maybe using SWSURFACE should do it. I am not so familiar with HW-SDL)

This sounds plausible. For the second graph, each 'jump' is where it drawing the lines takes long enough that it has to wait for the next vsync.

Looking at the second graph that would put the screen refresh rate at around ~100hz. That seems a little high?

 

[charlieb]

Thanks for your ideas, just to let you know I haven't dropped off the map I just haven't had too much time to spare but I will test the ideas soon (ish).

 

[charlieb]

Ok so I got some time to test these ideas. The graph below speaks for itself, sw_db_out is a double buffered software surface, sw_nodb_out is a single buffered software surface and hw_no_db is a single buffered hardware surface and hw_db_out is the original double buffered hardware surface.

The single buffered hardware surface is *not recommended* there was some very serious flickering and all the vertical lines were 45 degree diagonals, not good but stll the results are interesing. There seemed to be some really bad vertical hold issues I guess caused by the vsync interfering with the line drawing. Do not use this mode