Negative Render Time for iPhone Internal Profiler

A project we’re working on was performing badly on the main menu system on the iPhone 4, and I was trying to use the internal profiler to determine what the issue was.

The number of draw calls and verts/tris was very low but the performance was poor compared to the 3GS. To make matters stranger, the amount of time the internal profiler claimed it was spending on rendering was a negative value.

Here’s an excerpt from when the negative time was . . . lowest?

----------------------------------------
iPhone Unity internal profiler stats:
cpu-player>    min:  2.8   max: 25.3   avg:  4.7
cpu-ogles-drv> min:  0.6   max:  5.4   avg:  0.9
cpu-waits-gpu> min: 24.1   max: 63.4   avg: 47.3
 msaa-resolve> min:  0.0   max:  0.0   avg:  0.0
frametime>     min: 33.2   max: 70.4   avg: 55.0
draw-call #>   min:  10    max:  12    avg:  11     | batched:    12
tris #>        min:    24  max:    96  avg:    80   | batched:    63
verts #>       min:    48  max:   192  avg:   161   | batched:   127
player-detail> physx:  0.7 animation:  0.0 culling  0.0 skinning:  0.0
batching:  0.1 render: -45.6 fixed-update-count: 1 .. 4
mono-scripts>  update:  1.4   fixedUpdate:  0.0 coroutines:  0.5
mono-memory>   used heap: 2445312 allocated heap: 2801664  max number
of collections: 0 collection total duration:  0.0
----------------------------------------
iPhone Unity internal profiler stats:
cpu-player>    min:  2.8   max:  6.8   avg:  3.1
cpu-ogles-drv> min:  0.7   max:  4.6   avg:  0.8
cpu-waits-gpu> min: 41.8   max: 63.4   avg: 52.4
 msaa-resolve> min:  0.0   max:  0.0   avg:  0.0
frametime>     min: 47.5   max: 69.2   avg: 58.3
draw-call #>   min:  12    max:  12    avg:  12     | batched:    14
tris #>        min:    96  max:    96  avg:    96   | batched:    82
verts #>       min:   192  max:   192  avg:   192   | batched:   164
player-detail> physx:  0.3 animation:  0.0 culling  0.0 skinning:  0.0
batching:  0.1 render: -50.9 fixed-update-count: 2 .. 4
mono-scripts>  update:  0.4   fixedUpdate:  0.0 coroutines:  0.5
mono-memory>   used heap: 2445312 allocated heap: 2801664  max number
of collections: 0 collection total duration:  0.0
----------------------------------------
iPhone Unity internal profiler stats:
cpu-player>    min:  2.8   max: 21.2   avg:  4.4
cpu-ogles-drv> min:  0.7   max:  3.3   avg:  0.8
cpu-waits-gpu> min: 26.1   max: 64.1   avg: 50.1
 msaa-resolve> min:  0.0   max:  0.0   avg:  0.0
frametime>     min: 46.3   max: 70.3   avg: 57.2
draw-call #>   min:  11    max:  12    avg:  11     | batched:    12
tris #>        min:    36  max:    96  avg:    85   | batched:    68
verts #>       min:    72  max:   192  avg:   170   | batched:   137
player-detail> physx:  0.6 animation:  0.0 culling  0.0 skinning:  0.0
batching:  0.1 render: -48.3 fixed-update-count: 2 .. 4
mono-scripts>  update:  1.1   fixedUpdate:  0.0 coroutines:  0.5
mono-memory>   used heap: 2457600 allocated heap: 2801664  max number
of collections: 0 collection total duration:  0.0
----------------------------------------

The only thing being rendered was a series of EZGUI panels and buttons. Any help figuring out what is going on with either the profiler or the game would be greatly appreciated.

I can’t speak as to the negative render time (very odd), but the fact that you’re having the problem on iPhone 4 and not 3GS tells me this is almost certainly a fillrate issue. Try getting the latest beta of EZ GUI which has a faster version of the transparent shader, or just use the built-in shader under Mobile/Particles/Alpha Blended. That may speed things up a lot. If not, then it sounds like you may be having overdraw: drawing over the same parts of the screen multiple times, eating up your fillrate. In that case, all I can recommend is trying to do less of that, such as by combining elements into a single image. Also, if you have any 100% opaque elements, put those on a separate atlas/material and use an unlit diffuse shader.

could also be that you have switched into opengl es 2. That will wreak havoc and you can disable it in AppController.mm (you do this from within xcode and you have to remember to check it). IIRC fixed function shaders are emulated (or something like that) in Opengles2 and it’s slow slow slow.

I ran into this because I am running ipad only which means settings have to be for ARMV7 which can get you into opengl es 2 mode. If you have ipad only app and use arm6+7 apple will reject you from app store.

don’t know why the appcontroller.mm has http on it, i didnt do that