Improving performance

[ptitSeb]

Here is the test (source + executable, with makefile, should compile with codeblocks or cdevtools, plain C, nothing fancy).

I load 4 larges texture for parallax background, and I build a small atlas for the sprites. I have 512 sprite on screen (but you can easily change the number in the code), and print out the number of SDL ticks needed to draw 300 frames.

I use eglport for the GLES context

Those nice textures come from OpenGameArts, flying things by bevouliin and the parallax background by Luis Zuno.

Very simple test (and not much comment in the crappy code), using GLES 1 only. It's a 2D scenario, and the drawing is a simple back to front, with no Depth test.

On my gigahertz, using Blend is 10% faster than Alpha.

 

[Ziz]

Improving Performance to more?

I did not read the entire Thread for yet

Maybe do next time? This thread is about improving the compilation of pmprogs application, not what users can do to make it faster.

but an Idea is to disable this Zram,because i understand that so:

Zram is a compressed ram and compress and decompress all over the Time make the Pandora little slower.

To get little more Performance then you can type:

sudo swapoff /dev/zram

As long as the application doesn't use MUCH ram, nothing will be compressed or decompressed. The zram is "just" a swap file, but in ram instead of the hard disk and compressed (otherwise it wouldn't make any sense at all...). Here is more information for you: http://wiki.ubuntuusers.de/zRam

Maybe it help a little for your searches for more Performance.

For me no Problem because when i need more Memory can i activate then my Swapfile if needed.

Edit: Oops its not the Performance of the Pandora what you need to get better?

Its for a Game?

Then another Idea is to copy the Game into the Ram and execute it from there when its not too big.

Why should this make things faster? He hasn't any problem with loading times afai understand. With your attempt the amount of free RAM gets even smaller and he would even need MORE time to load things, because first of all he would load anything to the ram and afterwards from the ram to the ram (e.g. from a PNG file in RAM to a SDL Surface or a texture in RAM).

 

[JonnyH]

Very interesting ptitSeb - that probably shouldn't be the case - It might be interesting to ruin with the 'DumpShaders=1' apphint, so we can actually see how the program generated for the gpu changes based on each path.

Any chance you could let me know which version of the powervr drivers you're using? I also might have a go with trying an es2 version and seeing if there's any differences. That would give us a couple more options in the shader (e.g. 'discard' and setting 'gl_FragColor.a = 0' to implement discard as part of 'blend'.

I assume in your test it is very much gpu-bound? If it's limited by the CPU most of my 'analysis' would be completely wrong.

For general performance considerations:

It's better to do a non-scissored (fullscreen) clear at the beginning of every frame - this saves a read of the 'last' framebuffer if you're just going to overwrite the whole screen anyway. The drivers detect this glClear() and optimise accordingly (It just sets the tile output mode to ignore any previous contents)

 

[ptitSeb]

Very interesting ptitSeb - that probably shouldn't be the case - It might be interesting to ruin with the 'DumpShaders=1' apphint, so we can actually see how the program generated for the gpu changes based on each path.

Any chance you could let me know which version of the powervr drivers you're using? I also might have a go with trying an es2 version and seeing if there's any differences. That would give us a couple more options in the shader (e.g. 'discard' and setting 'gl_FragColor.a = 0' to implement discard as part of 'blend'.

I assume in your test it is very much gpu-bound? If it's limited by the CPU most of my 'analysis' would be completely wrong.

For general performance considerations:

It's better to do a non-scissored (fullscreen) clear at the beginning of every frame - this saves a read of the 'last' framebuffer if you're just going to overwrite the whole screen anyway. The drivers detect this glClear() and optimise accordingly (It just sets the tile output mode to ignore any previous contents)

I'm using 4.03.00.02 version driver (1.6.16.3977).

The test should by GPU limited, it's doing mostly nothing on CPU side (well, that was the purpose, I hope I have succeeded).

Doing a GLES2 version should not be too much difficult, as, I used few GLES functions. I may try later, but feel free to do it before me

 

[JonnyH]

Very interesting ptitSeb - that probably shouldn't be the case - It might be interesting to ruin with the 'DumpShaders=1' apphint, so we can actually see how the program generated for the gpu changes based on each path.

Any chance you could let me know which version of the powervr drivers you're using? I also might have a go with trying an es2 version and seeing if there's any differences. That would give us a couple more options in the shader (e.g. 'discard' and setting 'gl_FragColor.a = 0' to implement discard as part of 'blend'.

I assume in your test it is very much gpu-bound? If it's limited by the CPU most of my 'analysis' would be completely wrong.

For general performance considerations:

It's better to do a non-scissored (fullscreen) clear at the beginning of every frame - this saves a read of the 'last' framebuffer if you're just going to overwrite the whole screen anyway. The drivers detect this glClear() and optimise accordingly (It just sets the tile output mode to ignore any previous contents)

I'm using 4.03.00.02 version driver.

The test should by GPU limited, it's doing mostly nothing on CPU side (well, that was the purpose, I hope I have succeeded).

Doing a GLES2 version should not be too much difficult, as, I used few GLES functions. I may try later, but feel free to do it before me

Sure, I'll write a gles2 version of this test. I don't actually have a pandora to test directly on, but have other omap3 devices available, so I'll try my best to get it 'working'

 

[ptitSeb]

Oh and by the way @kimixa: I agree for the glClear. I forgot it during the coding, and then it was to late in the night when I remembered it. I'll add later, see if it make a difference (it may influence a bit the results).

 

[JonnyH]

Oh and by the way @kimixa: I agree for the glClear. I forgot it during the coding, and then it was to late in the night when I remembered it. I'll add later, see if it make a difference (it may influence a bit the results).

If it does, I only expect it to affect the 'first' frame (As the driver knows the framebuffer starts undefined) - the other 299 should be exactly the same - non-optimal, but the same.

 

[JonnyH]

A bit of thread necromancy, but I kinda forgot about this - I did a quick implementation of a gles2 blend/discard performance test - I haven't got a pandora myself, so haven't actually been able to test it yet... If anyone gets round to actually running the thing, please let me know if it actually works! Link here https://github.com/JonnyH/pandora_dump

 

[pmprog]

A bit of thread necromancy, but I kinda forgot about this - I did a quick implementation of a gles2 blend/discard performance test - I haven't got a pandora myself, so haven't actually been able to test it yet... If anyone gets round to actually running the thing, please let me know if it actually works! Link here https://github.com/JonnyH/pandora_dump

Compiled fine, but when I tried to run it, I got:

sgx_bandwidth: main_es2.c:63: loadProgram: Assertion `status == 1' failed.

 

[mjohansson]

What framerate are you guys getting? If you are drawing 2D then try not drawing overlapping graphics on same Z plane, if 2 polygons occupy the same physical space it will drop the framerate like a stone, when I did work on a 2D game I gave all sprites on different background layer different depth values to circumvent that, but I have since learnt that the frustum depth space should always be as low as possible otherwise you might get gaps between sprites because of inaccuracy at least I think thats why I got them in my earlier projects. And this is regardless of Depthtest on or off! So try drawing all graphics that overlaps or might overlap other graphics on different depths and have those depth values be like +0.001f to keep frustum as low as you can get away with and still have many possible layers of depth planes. I don't think its safe to use lower then 0.001f as difference.

 

[JonnyH]

I messed up the shader just before I pushed it (Don't rename something without testing kids!) - I just fixed that. I can't seem to run it on my workstation as I get noise in the images from SDL_images, but it might work now...