Improving performance

[pmprog]

So my game has made some pretty nice progress, and I'm getting to the end of the core code, so I thought I'd do a Pandora compile and see how it fairs on there.

The performance was okay and certainly playable, but not exactly outstanding considering how simplistic it is.

So I ran "perf record", and this is everything > 1% overhead (I can post the whole file if it's worth it?)

Spoiler

# Overhead Command Shared Object Symbol
# ........ ......... ................................................................... .................................................................................................................................................................................................
#
16.72% SJKTdebug /usr/lib/libGLESv2.so.1.4.14.2616 0x1cc60 d [.] 0x1cc60
8.59% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libvorbis.so.0.4.7 0x2bd8 d [.] mdct_butterflies.isra.0
6.94% SJKTdebug /mnt/utmp/codeblocks/usr/lib/liballegro_audio.so.5.1.8 0x7800 d [.] read_to_mixer_linear_float_32
5.98% SJKTdebug /usr/lib/libsrv_um.so.1.4.14.2616 0x202c d [.] PVRSRVWaitus
5.10% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libvorbis.so.0.4.7 0x5434 d [.] mdct_backward
3.86% SJKTdebug /mnt/utmp/codeblocks/usr/lib/liballegro_audio.so.5.1.8 0x5e54 d [.] _al_kcm_mixer_read
3.38% SJKTdebug /lib/libc-2.9.so 0x6f300 d [.] memcpy
2.76% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libvorbisfile.so.3.3.6 0x6c98 d [.] ov_read_filter
2.70% SJKTdebug /usr/lib/libasound.so.2.0.0 0x1d3c8 d [.] 0x1d3c8
2.69% SJKTdebug [kernel.kallsyms] 0xc0050618 k [k] do_sys_times
2.54% SJKTdebug /lib/libm-2.9.so 0x15da0 d [.] floorl
2.49% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libvorbis.so.0.4.7 0xc954 d [.] vorbis_synthesis_blockin
2.04% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libpng14.so.14.12.0 0xa2c0 d [.] png_read_filter_row
1.83% SJKTdebug [kernel.kallsyms] 0xc0201ee0 k [k] __memzero
1.70% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libvorbis.so.0.4.7 0x1da18 d [.] vorbis_book_decodevv_add
1.60% SJKTdebug /mnt/utmp/codeblocks/usr/lib/liballegro_image.so.5.1.8 0x5504 d [.] really_load_png
1.34% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libvorbis.so.0.4.7 0x1b2c0 d [.] mapping0_inverse
1.26% SJKTdebug /mnt/utmp/codeblocks/usr/lib/libvorbis.so.0.4.7 0x161bc d [.] floor1_inverse2

None of it is in my code, and the rendering isn't exactly complicated with less than 20 elements on the screen at all times (well, depending on how Allegro draws text I guess).

I'm not exactly sure what I can do to improve the performance. Does anybody have any ideas what I can look at?

 

[sebt3]

Sound could/should be threaded.

Images manipulation should be done only during init.

Never ever use long datatype, 64b data manipulation isnt specially fast on a 32b machine, specially not on ARM. float should be enough precision for a game and as you do many floorl, probably even int32_t could do here.

otherwise an apitrace/pvrtrace could be usefull. But the SGX driver is indeed very costly on the CPU (the memcpy are probably from it too). and you can do nothing about it beside making sure you minimize the number of calls to it.

 

[pmprog]

There's no floorl in my code - I'm assuming that's from libvorbis (calling 'floor1_inverse2', unless that's coincidence). I might try turning the audio off and seeing if it alters performance, but I'm not super keen on dropping audio from my game

I have only a single 64bit int which is used as a game frame counter (for network sync).

Does threading make any difference on a single core processor? I must admit my framework isn't really designed for a multithreaded approach, though I could try and shift all rendering off to a seperate thread.

Thanks

Edit: I've never tried (or heard of) apitrace or pvrtrace, so I'll give them a try later.

 

[Rockthesmurf]

Could switch to the tremor version of ogg vorbis, doesn't take very long to do and should be beneficial on Pandora. I don't think I have ever seen a profile log where most of it is to do with audio, kind of interesting! Also, in terms of the actual game, is the audio doing anything less than optimal? Hard to predict quite what (but things like leaving music tracks playing with 0 volume instead of pausing).

 

[pmprog]

Well, audio is kind of hard to do anything with, as this is all my audio code:

https://github.com/pmprog/SuperJumpKickTurbo/blob/master/Framework/Sound/audio.cpp

All I do is tell Allegro to play and stop really. Unless maybe I can change the settings of the Voice or Mixer?

 

[crow_riot]

you only need to link against libtremor instead of libvorbis to have the fixed point decoder working.

have never worked with allegro, so just guessing here: could changing the mixer format from ALLEGRO_AUDIO_DEPTH_FLOAT32 to ALLEGRO_AUDIO_DEPTH_INT16 help?

 

[pmprog]

Well, as I use petitSeb's Allegro build so I don't actually link libvorbis myself, so not much I can do on that (well, unless I rebuild his library, which I could try)

I will try changing the audio depth on the mixer though.

Thanks

 

[notaz]

From this output it looks like allegro isn't a good choice for pandora overall, unless it can be switched to integer mode somehow.

 

[pmprog]

I hope by changing my mixer to Int16 and linking Tremor then makes vast improvements, because I (personally) think Allegro is so much better than SDL (though I haven't played with SDL v2 yet).

It did worry my on the OpenApocalypse project that JonnyH has started rewriting all the drawing functions, but he knows what he's doing. Shame he's totally baffled me...

 

[pmprog]

could changing the mixer format from ALLEGRO_AUDIO_DEPTH_FLOAT32 to ALLEGRO_AUDIO_DEPTH_INT16 help?

This does help a bit.
I've not tried rebuilding Allegro with Tremor yet, next on my list of things to try.

Network play is okay, but quite a bit of lag, despite playing on a LAN, and I got a desync during one game

 

[ptitSeb]

I'll try to recompile Allegro 5 with tremor later also...

 

[pmprog]

I made some great improvements with the rendering. This was more to do with the way I was handling screen scaling than any GLES/Allegro issues.

As the native resolution is 800x480, I just removed the scaling functionality and it seems to perform a lot better. I have, however, broken my UI library, but that's not a big deal, as I was going to replace the current menus anyway.

I didn't get around to trying to compile Allegro with Tremor, but I'll hopefully still give that a go at some point.

Should have a PND soon for some beta testing

 

[ptitSeb]

I have looked at Allegro, and in fact, it support compiling with Tremor already. Just lauch ccmake . on the my git and activate Tremor (plus PANDORA, HAVE_GLES and GLES2) to get it.

Next Codeblocks will have it anyway.

 

[pmprog]

it support compiling with Tremor already

I saw that, but just haven't built it.
One of the results from my performance checks was that Allegro always leaves alpha blending on, regardless of if the user set a blending method, so I might try (if I get time) to make some changes so you can actually disable it.

I've forked your git, so if I make the changes, I'll send you a pull request.

 

[ptitSeb]

Ah, blending is bad for perf, but not as bad as Alpha_test / discard. So make sure that there is no discard in the shader when bending is of too (I haven't checked at all all this code).

 

[JonnyH]

it support compiling with Tremor already

I saw that, but just haven't built it.

One of the results from my performance checks was that Allegro always leaves alpha blending on, regardless of if the user set a blending method, so I might try (if I get time) to make some changes so you can actually disable it.


I've forked your git, so if I make the changes, I'll send you a pull request.

I prototyped the change here: https://github.com/JonnyH/allegro51-pandora/commit/c60ce3217e073a3529b08aabe4542728836ac14f

I haven't actually tested this on real hw, so that would be useful!

To effectively disable blending, set the blend mode so that src is ALLEGRO_ZERO and dst is ALLEGRO_ONE.

I haven't actually confirmed that setting the glBlendFunc() to the same (ZERO/ONE) doesn't effectively disable GL_BLEND as far as these performance changes are concerned...

As for discard/alpha test, that (on sgx) has about the same performance impact as blending. The major costs - of reading in the src buffer, and disabling overdraw optimisation (powervr hardware normally avoids rendering pixels if it knows they're going to be 'covered' by other geometry anyway) - are the same for both.

One thing to keep in mind is that the shader will have to run through all paths, even if the fragment was 'discarded' in a branch earlier, so keep that in mind if writing 'mega shaders'.

 

[ptitSeb]

@kimixa: nice (for the source code change, very simple, that's good), but I have to disagree about the discard / blend.

The cost is not the same, because of the tile rendiring approach sgx is using, discard as a bigger effect than the read buffer, there are some tile cache issue too not found in glBlend.

If I found some time, I'll do some simple bench about that...

 

[ingoreis]

Improving Performance to more?


I did not read the entire Thread for yet 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


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.

 

[Rockthesmurf]

Alpha test having a high cost is because alpha testing means the Z value isn't known until after the pixel shader has run which wreaks havoc for hidden surface removal/depth sorting which is part of the tiled deferred rendering pipeline that a lot of mobile/embedded GPUs use these days.


If ptitSeb does a proper test with that's shows actual cost that would be cool.

 

[ptitSeb]

I have written a simple test (using GLES|1.1), using only 2D sprites, and the difference between Alpha & Blend is marginal, but Alpha is slower.

I'll publish the sources here later (too late now).