Author Topic: GPmark for Opendingux  (Read 6205 times)

Optimus (OP)

  • Posts: 107
Re: GPmark for Opendingux
« Reply #20 on: September 10, 2012, 01:10:33 pm »
Use -O2 instead of -O3 on the Dingoo. It gives better results.

Yeah, I realized that most makefiles use -O2 and I wondered why.
Maybe because of no inlining optimizations that would kill code cache? (In my benchmark though -O3 and -O2 yield the very same results, just tried it again)
I am wondering now if the same applies with Gamepark handhelds. Should try to recompile stuff.

Optimus (OP)

  • Posts: 107
Re: GPmark for Opendingux
« Reply #21 on: September 10, 2012, 05:53:01 pm »
My mistake, it wasn't Caanoo that had accelerated SDL, it was the older GP2X.
With HW_SURFACE on Caanoo it's funny, scores get even lower.
With HW_SURFACE on GP2X I get better scores, especially the blitting and Plasma reaching Caanoo, wow. But lot's of flickering.

I cannot understand this. I have tried to use LOCK UNLOCK surface, DOUBLEBUF and various alternatives and read the SDL docs again and again. I cannot understand how to make HW_SURFACE without flickering on both Dingoo and GP2X.

I do understand what it means. The screen->pixels pointer points directly at the hardware videoram now and not a software buffer that gets blitted later to the videoram. When SDL_FLIP is called, the vram switches to display that page. Whatever it happens, the execution of the code continues before the displaying is completed (to win time). So, if I render in a second videobuffer as long as the first videobuffer is displayed (both are hw vram pages) then it's ok and not flickering. But SDL does not give me this opportunity. It does not give me the opportunity to get the vram pointer from second page. It does all automatically behind my back. But the result is like this flipping is not happening and I draw at the same page that is being displayed. So far only SW_SURFACE works fine (even if slower) for these benchmarks.


  • Posts: 1667
    • My devblog
Re: GPmark for Opendingux
« Reply #22 on: September 10, 2012, 07:14:43 pm »
SDL offers you the possibility to use double buffering. This allow you to have the performance of hardware surfaces, without any flickering.

The fact that all benchmarks won't go above 78fps when double buffering is activated is because the buffer flip function waits for the previous frame to finish its transfer to the hardware, if not already done, and the hardware is capable of pushing 78 frames in a second. If that limitation wasn't there, you'd obtain the same numbers you can have with hardware surfaces only.

Just do a quick comparison of the benchmarks that use to push less than 78fps on dingoo, with gpmark compiled with SDL_SWSURFACE then SDL_HWSURFACE | SDL_DOUBLEBUF. For those benchmarks, you'll see that the second binary is much faster while outputing a nice and clear picture.

The reason why it's flickering on GP2X and Caanoo, is that while SDL will gladly accept the SDL_DOUBLEBUF flag, the kernel needs to support it. This is the case for OpenDingux, but neither the legacy Dingux kernel, nor the kernels on GP2X and Caanoo implemented it. Which is a shame really, since that would be a huge improvement.
« Last Edit: September 10, 2012, 07:17:35 pm by Ayla »

Optimus (OP)

  • Posts: 107
Re: GPmark for Opendingux
« Reply #23 on: September 12, 2012, 01:05:47 pm »
Ok, I understand. So, it does make this automatically. I don't have to mind about which page I am writing to.
But of course this is quite useful for a game but not for a benchmark. For the benchmark I think I will keep the SW_SURFACE version except if I set an extra option for running the tests as fast as possible reagardles the flickering just for the kicks. Though you are right, even the tests that were below 78 showed improvement.

p.s. GP2X btw, does vsync properly with SDL_DOUBLEBUF without flickering in it's hardware accelearted SDL libs (coded by Paeryn). Now I remember I have used these libs once on ReReRecycle demo on GP2X first time. But yes, from the other side Caanoo does not seem to have support for hw buffers in SDL.

p.p.s. Another option would be to run the effects rendering independently from the surface blitting, maybe checking somehow if blitting has finished and if not continue rendering the next frame (thus skipping frames). The number of frames counter will be in this separate thread too. So blitting will be vsynced and accelerated but in the meanwhile more than one frames might be rendered and counted in the results. I will think about it (thinking something similar for my android phone where I want to port gpmark oneday too, damn thing doesn't let you disable vsync and I read somewhere it's universal, not good for benchmarking graphics :P). Maybe in a new improved gpmark version (don't know when) I will add more options and stuff for Dingoo and other platforms.
« Last Edit: September 12, 2012, 01:08:11 pm by Optimus »


Post a new topic