Optimizing Astromenace

[notaz]

Since game have 15fps in menu and the main issue is CPU load

I think we decided it's GPU load actually.. 110MHz GPU on classic/rebirth pandoras probably can't push it, 200MHz one on 1GHz pandoras might be better at this.
There are also tools for profiling this specific GPU, pvrtune or pvrtrace or something like that, I can't find usage instructions now but I know somebody had them running on pandora.

http://www.imgtec.com/powervr/insider/pvrtrace.asp

 

[crow_riot]

Since game have 15fps in menu and the main issue is CPU load

I think we decided it's GPU load actually.. 110MHz GPU on classic/rebirth pandoras probably can't push it, 200MHz one on 1GHz pandoras might be better at this.

agreed. with 23000 triangles you'll never get decent framerate on the pandora.

from my experience it's maxed by few thousand and those well optimized with little to no state changes in between that you'll get a decent framerate. it'd be better to try optimizing/poly-reducing the models before trying anything else.

 

[viewizard]

Since game have 15fps in menu and the main issue is CPU load

I think we decided it's GPU load actually.. 110MHz GPU on classic/rebirth pandoras probably can't push it, 200MHz one on 1GHz pandoras might be better at this.

Sebt3 have an experience with previous astromenace porting and share idea about possible CPU-connected low FPS rate. Now we know for sure, that game fps not connected to CPU load.

I see 2 possible issues, unfortunately, they both hardware-related:

1) GPU speed, as mentioned notaz.

2) system bus bandwidth limitation. Since ARM systems GPU don't have separate VRAM with its own bus, system bus bandwidth could be bottleneck (even VBO use main system bus, and this is really sad).

Not sure about optimizing/poly-reducing for 3d models and results... some of 3d models already low-low-poly :lol: in order to launch game on 10-12 years old PCs...

dbluelle, you can test this (how much poly pandora need for good FPS) by modify menu background scripts (see RAW_VFS_DATA/SCRIPT/ folder - menu1.xml, menu2.xml and menu3.xml files). Just remove some <TimeLine> blocks to reduce ships on scene (don't forget recreate vfs file).

 

[crow_riot]

oh never looked at the polycount of the models ;-) yeah 10 year old models should work fine. bad tip i guess

 

[dbluelle]

I couldn't get the "pvrtrace" tool to run on with the pandora

( if I use the replacement GLES/EGL libraries the game segfaults on startup...)

However the "pvrtune" tool runs and produces some data...

But I'm having some trouble interpreting the results:

- it has large TA gaps, but no 3D gaps

- USSE load: pixel is high

- USSE clock cycles per pixel is low

According to the "Five common bottlenecks" explained in the PVRTune user manual,

the game seems to be either fragment limited or bandwidth limited.

So how can we optimze fragment/bandwidth limitation?

I've added the recorded .pvrtune file so anybody with some knowledge on how to interpret these results can 

have a look at the data

pvrtune_data.zip

 

[viewizard]

Hmm... yeah, looks like hardware limitations... frankly speaking, I don't see how this can be "fixed" without deep 3d models rework in order to render around 3000-5000 triangles. But, this will take a lot of time and when all 3d models poly count will be reduced in 7-8 times, result will be... ugly imo.

Btw, can any one test this port on Pandora 1GHz? As I see, only this one have 200MHz GPU speed and 200MHz system bus.

 

[dbluelle]

I've added a few small improvements on the star system rendering and disabled alpha testing, so  now I get around 25-30 fps on the main menu (without sound).

 

[dbluelle]

I've uploaded a beta version which is quite playable to the repo. 

The main menu runs with ~50 fps and in game I can keep it above 20 fps most of the time

 

[rohezal]

The main menu runs with ~50 fps and in game I can keep it above 20 fps most of the time

On a ghz oder a classic pandora?

I've added a few small improvements on the star system rendering and disabled alpha testing, so  now I get around 25-30 fps on the main menu (without sound).

Does the GPU have texture caches? Cache misses are very expensive on gpu. Lowering the texture size can reduce cache misses (and is easily done via gimp and co, without 3d modelling).  

Can you try to track which model has most gpu load? I am not a good 3d artist, but a single ship could be possible, if it is not too much work...

Sample work:

http://forums.savage2.com/showpost.php?p=530503&postcount=3

https://www.youtube.com/user/derschrott

 

[dbluelle]

The main menu runs with ~50 fps and in game I can keep it above 20 fps most of the time

On a ghz oder a classic pandora?

That's on a rebirth unit at 600 MHz. (Almost the same on 800 MHz)

I've added a few small improvements on the star system rendering and disabled alpha testing, so  now I get around 25-30 fps on the main menu (without sound).

Does the GPU have texture caches? Cache misses are very expensive on gpu. Lowering the texture size can reduce cache misses (and is easily done via gimp and co, without 3d modelling).  

I've played around with smaller texture sizes but that doesn't show any improvement in speed so far 

 

[rohezal]

If you want to change models, I have looked at open game art. There are some space ships (low poly) and even some from astro menace. Maybe if you can find out what model has the biggest impact, somebody could replace it. I don't have a pandora (or much time). But you can change a ship model (lets say the most common enemy) by a simple box (small, violett 1x1 texture). When the speed improves, you know where the problem was. If not change other / more models. If the doesn't improve much it is something else.

Good open source models:

http://opengameart.org

 

[Exophase]

Alpha testing is very expensive on SGX530, something dbluelle probably picked up on. There was one report a long time ago that said that it cut performance in half (which sounds about the same here). That seemed to apply just for having it on, regardless of how many fragments actually failed the test. I'm not sure what the exact mechanism is here but it's because of the TBDR nature of the renderer, where the top-most visible pixel is determined before any pixels are drawn. It may actually render the entire tile twice, first just to mark somewhere which pixels are discarded..

Does the GPU have texture caches? Cache misses are very expensive on gpu. Lowering the texture size can reduce cache misses (and is easily done via gimp and co, without 3d modelling).

There are texture caches, I don't think anyone would make a GPU without them or some kind of fast dedicated texture memory. He did say he tried reducing texture size, this is what he said about that:

- Reducing texture width and height by 1/2 or 1/4 does lead to around 1-2 fps more.

I don't know what the original format of the textures are but converting to PVRTC would be a good alternative. Not sure if those reduced textures were just clamping the highest LOD levels or giving an LOD bias across the board. If it's the former then it may not have applied to all pixels, while savings from PVRTC would.

Before looking into any options that reduce geometry load he should see how much time the GPU is actually spending on geometry. It's a unified shader so less vertexes will give more cycles for fragment shaders, but it might not be a huge amount. It might be a good idea to try making the polygons solid color only or even make them all both front and back face culled to make them not even render (not sure if the drivers will optimize this out though), to get some more data on how much time is spent where.

 

[dbluelle]

I've converted everything to PVRTC now, but that doesn't significantly increase the fps.

However it does heavily reduce the loading time of the game, so I will keep that in anyway.

One of the main bottlenecks seems to be the handling of particles during the game.

Especially when explosions occur, the cpu usage goes up to 99% leading to occasional stuttering of the game.

 

[rohezal]

Does the explosions use a lot of alpha channel textures? The alpha test is pretty expensive on our GPU. Is it possible to change the images from rgba format to a format, where are just transparent pixels (more ugly, but maybe we faster)?

 

[dbluelle]

Does the explosions use a lot of alpha channel textures? The alpha test is pretty expensive on our GPU. Is it possible to change the images from rgba format to a format, where are just transparent pixels (more ugly, but maybe we faster)?

Okay, I've done that and together with removing some of the particle systems it seems to lead to less stuttering! B)

So I've uploaded a new version to the repo.

 

[viewizard]

dbluelle, I just found possible memory overflow issue in code for Pandora. Please, take a look:

https://github.com/dbluelle/pandora-astromenace/blob/master/AstroMenaceSource/GraphicFX/SkyBox.cpp#L59

you need

int VFV = RI_3f_XYZ | RI_2_TEX | RI_DUBLICATE_TEX_COORD;

or

you'll need more space in buffer for 2 more float (for separate second textrures coordinates)

float buff[(5+2)*4]; ... and you'll need add some more lines to fill second textures coordinates for each vertex (if you need second textures coordinates)...

or

just revert code to previous upstream code version (with two rendering pass), imo, the best chose for you, since you disable stars layer anyway.

the possible memory overflow point (remember, default value is RI_SEPARATE_TEX_COORD):

https://github.com/dbluelle/pandora-astromenace/blob/master/AstroMenaceSource/Core/RendererInterface/OGL_Draw3D.cpp#L218

now, you have VFV that will operate with memory "(5+2)*4 floats", but provide (and have reserved) only "5*4 floats". This works somehow only because you provide stride "5 floats". So, each vertex internal stride set to "7 floats", but then forced back to "5 floats"... but the last one should use 2 floats of memory you have not reserved for use. So, we have possible memory overflow issue here.

Hope, this help in you work.

 

[dbluelle]

Ah, now I understand what the RI_2_TEX is used for.  :rolleyes:

Removing the stars layer gets 2-3 more fps, so I reworked the skybox handling ( I hope I have done it right this time   )

Thanks for the help.