Unity performance on Mobile

I have seen weird performance issues when building to mobile phone. Specifically on iPhone 7, the same scene runs fine one time and if i continue to play to the next scene, then go back to the previous scene, the frame rate drops dramatically.

It doesn't seem to be an issue in the scene itself, otherwise it would have ran poorly from the beginning.

Typically the scene has around 30k Tris and 50 SetPass calls. Which in my experience should run just fine on an iPhone 5, nevertheless on iPhone 6, or 7!

Anyone having this issue?

 

Is the phone perhaps getting too warm? As far as I know, phones often reduce performance to cool down again, to avoid overheating. So if your game causes heavy resource (CPU/GPU) utilization, your phone might just heat up during these 5 minutes and then reduces performance to cool down. Due to this limitation, profiling phones can be quite tricky, as you need to profile under the same temperature settings.

I believe there exists even an Unite or GDC Talk about this topic, but I was unable to find it. If anybody has the link, please post it.

 

I think these are the video you're talking about.

 

The behaviour of performance degradation between scenes if using LoadScene will 9 times out of 10 actually be an issue with an object which has DontDestroy flag, basically any persistent objects like that, or any static variable references you have, which aren't set up again.

Tell me your console errors, if any when doing the exact steps to reproduce this behaviour.

 

Have you tried to take a look on profiler with your iPhone plugged?

And don't forget your friends in iOS and tvOS, you may find gems there.

 

Also as for DontDestroy flags, i don't have any, however i do have one static int, but i don't understand what do you mean by it's referenced but not setup again?

 

The phone does indeed heat up during gameplay. The decrease in frame rate does appear after the heat is noticed.
How do you avoid the phone heating? i mean what is the technique behind that? i see people saying to load everything up front and such, but i don't know how is that done with Unity!

 

OK in this case then it's likely throttling. The solution is to be less cpu / gpu intensive (optimisation) as others have suggested. This will reduce the work required. Can also limit framerate for a quick fix in addition.

References are destroyed on scene load because the original object no longer exists. Static values do not change between scene loads, so it can often be pointing to a null address which I've seen happen a lot with Unity users not aware of the situation. This is only applicable for reference types, not int, float etc (value types).

For some people instead of crashing, it can lead to performance degradation that's masking a crash so I had to enquire if that was the case.

 

Great stuff, one tends to forget, specially when long period passes by when creating serious games.

 

I finally remembered what video it was \o/ The relevant talk starts at 12:11min. However, the entire video is actually a very good watch.

Epic optimized their game to run with 60fps, but they limited it to 30fps. Thus the device was half the time in idle and had time to cool down during this time.

 

i see this when profiling the actual iPhone 7.
Which seems to be taking too much Time ms (29.3).

Uncounted time between: PostlateUpdaterofilerEndFrame and Initialization.PlayerUpdateTime
Is that normal?

 

Will definitely watch that, i just finished watching the other two videos that were suggested by Sailendu.

 

Too slow, you should avoid effect applying on OnRenderImage when targeting mobile.
Always do the work between OnPostRender and OnPreRender.
OnRenderImage is too inefficient.

Other tips are:

• Reduce your rendertexture/texture size to acceptable limit, they are main heater.
• Relax you AI/pathfinding code to time based instead of frame based. Save lot of cpu
• Have atlas texture global in shader(not global in c#), to avoid unnecessary texture reload to gpu. (probably no need to do that in today release? I am not sure)

 

This video has some great stuffs, it is for UE4 but many of the principles described here can be used by everyone. Thanks for posting it here.

 

I only have effects running in the menu scene and nothing in the actual gameplay, but that still shows in the gameplay scenes.

 

If you have number of effects, better stack them between OnPostRender and OnPreRender, without extra rt reading cost per effect.

Return to your main question, what is your unity version?
Significant framerate dropping on switch scene is worrying, does it happens every time you build and play?

 

2017.3.1 and it happens every single time I test the game. I have done so much optimization and it’s driving me crazy that it’s not helping.

Dropping the draw calls and tris to real low values that usually work fine on older phones, but causing performance issue on iPhone7, is too strange, that’s why I turned to the forum when I got stuck with nothing else that I can do.

I even went as far as drawing shadows on terrains, to save performance, 2d plane for characters shadows, no post effects at all and of course atlasing, baking static objects and low tris environment.

Then I go to test the game and I still get the same problem, frame rate drops right down, after going from one scene to another and back.

 

Real great stuff, I got some stuff done somewhat close to what they have done, but these guys are so good, it’s good to have such techie guys on your team!

 

If it works on older phones but iPhone7, probably graphics API bugs in 2017.3.1.
Could you try swapping graphics API?

You should submitted bug report...

(hugs) I am also feeling sick of seeing new/revived bugs from each release.
Our best bet is on the LTS release...

 

When you connect a profiler, what does it say is slow?

 

http://clickhurghada.com/files/ProblemiPhone7-01.jpg
http://clickhurghada.com/files/ProblemiPhone7-02.jpg
http://clickhurghada.com/files/ProblemiPhone7-03.jpg

Screenshots of the profiler while the device is running.

 

"Unaccounted time between..." isn't really helpful, too bad.

I recommend to give the Xcode profiler a try as well. Xcode not only provides data about CPU usage, but GPU and battery consumption as well. Perhaps it turns out the CPU just waits for the GPU to finish, who knows.

The CPU graph in Xcode should be able to reveal what that unaccounted time in the Unity profiler actually is. Here is an Unite talk that provides some basic information on how to profile your game in Xcode, it starts at 2:57min.

 

If that only occurs in IPhone7 but not old phones.

• Try switch graphics API from metal to GLES2, and build again.
• Next try is wear off all effects

 

http://clickhurghada.com/files/ProblemiPhone7-04.jpg

This is Xcode showing how bad the frame rate is, and that's in the main menu, that has only one character with 6500 Tris, the camera has (color correction, antialiasing and bloom post effects), NGUI with one atlas.

Yet frame rate after going back to the menu drops to 14, that's on iPhone 7. Even character idle animation is so slow.
When the game starts up, the menu is fine and i can go up to 60 fps. Playing in one of the gameplay scenes, and going back to menu or any other scene, frame rate drops right away.

 

already building with GLES2, not using metal as it's heavy on mobile.

 

Really? I found Metal save more battery (edit: just for me, probably depends on implementation)

Does the problem happens on other early unity release?

All the swapping API and Unity version is to narrow down the problem, you can change back to gles2 after identifying the broken part.

 

It shows the bottleneck is GPU. Now you need to dig deeper into what specifically is causing the graphics side to be so slow.

Did you enable GPU profiling in Xcode already? This will provide detailed information what's going on and how much time each of these things cost. Perhaps Unity's Frame Debugger gives some insights too.

Speaking of that, enabling GPU profiling in Xcode normally has a negative impact on performance. You don't always play/test the game running in Xcode with GPU profiling enabled, right? Because that could also be one reason why it runs slow(er).

 

I only run the GPU profiling when trying to find out what's causing the low performance. That has only been for yesterday and today since i was advised by some replies.

Problem is profiling is not easy nor is straight forward and no resources online that guides you through understanding the outputs while profiling. Most items down the stacks will end up giving 0x105be then some other digits. Not very helpful.

http://clickhurghada.com/files/ProblemiPhone7-05.jpg

I keep disabling things and building back and forth to know what exactly is causing this, but no luck so far.
The image from Xcode that shows the frame rate at 14, is just an example of how things go so slow, when really there is nothing in the scene. It's a menu, that has not even one update or fixed update function. Only a single animator to animate the character with one animation(idle).

 

After spending more and more time with Unity Profiler i found out that draw calls are not the same as SetPass calls.
Not sure why, but the problem is all trees in the scene wether it's in the camera frustum or not are counted in the Draw Calls, but not counted in the SetPass call. Huge miss lead here.

So trees are showing as 222 Draw Calls in the profiler, but only 38 in the SetPass calls.
But from what i see, the profiler draw calls are the ones that affect the performance on the iPhone. Is there something broken with Unity?

 

Don't waste your time.
If the project doesn't break in previous Unity release, file your report and submit.

 

Found the problem.
Profiling and optimisation tips for mobiles

Turns out the new phones have thermal heat problem, since they have high performance CPUs, GPUs packed in a small device, so intense game play for 2-3 minutes will cause the device to drop in frame rate from 60 to lower than 20 if heated. Then it might take the device up to 15 minutes to cool down for the frame rate to go back to normal!

Reading that thread made everything clear. New phones are high in performance for none intense gameplay, specially for more than couple of minutes. What a bummer!

Bottom line, should not let the device heat up by all means. Which means going back to optimization as if you were developing for iPhone 4 and 5. Unless your game style is to let the player play for 2-3 minutes then take him back to the main menu for the device to cool off.

 

set your target fps to 30, thats very basic.

 

That, and general optimisation across the board. The less work your device is doing to get the desired result the better it is for heat and battery life even if you've already hit your target frame rate.

Also, hats off to @Peter77, you nailed it!

 

Can't agree any more.
Ideally, 30fps is still too much in a game when screen is totally idle, they should stop rendering(in game) and only keep watching for touch event and other interrupt(notification events).

I feel sad when I see a great game have poor battery management.

 

I already have the frame rate at 30. Even though some scenes are okay at 60.
One thing that i don't get fully, it says to drop frame rate when it's so intense and raise it when you are in menu scene for example. does that mean that i should keep adjust the device frame rate at run time in the actual game release?

 

One more thing that i don't get in Unity, which used to be fine before.
I have those 222 draw calls from trees, so i made one atlas for all and combined mesh. Still 222 draw calls, nothing changed. If disabled the whole thing draw calls go down to 36, which is for the rest of the stuff in the scene.

 

You should optimise your menu scene rendering. Read my suggestion above.

Target frame rate at 60 means, I am telling my iPhone to draw on every 16.6ms, while target 30fps means draw on every 33.3ms.

e.g. I am now setting target fps 30. (1/30*1000 = 33.3ms)

• If you game is very optimized, the engine could finish the job within 5.2ms, allowing the theoretical fps to 192. Since you setting fps 30, your iPhone won't go crazy fps, and instead enjoying (33.3ms - 5.2ms = 28.1ms)idle time every second to cool the hardware.
• However, if you game runs too heavy, and the engine failed to finished the job within 33.3ms(e.g. 80ms), the frame rate drops to 12.5, and no idle time. The worst thing is, smart phone cpu could overclock in this situation, forcing the engine to finish job at within 33.3ms, and newbies love to abuse this by targeting a higher fps to ignore the actual problem.

 

Thanks for our suggestion in the above post, but I couldn't really understand when you said "Always do the work between OnPostRender and OnPreRender." Are these used for stuff like post processing? Can you please throw some more light on this topic.

 

Go to frame debugger, they will tell you failed to batch objects more than xxxx vertices. Split your trees mesh util the batch work, there is a balance between draw call and fill rate.

 

OnRenderImage copy camera output from src to write to dest, the good side is non-coder/beginner can add multiple effects without solving the conflict between effects, because the src from OnRenderImage is the final camera image from the previous effect or camera output.

What is the bad for mobile, especially screen effect on high res retina.
For one effect, post effect on OnRenderImage force copying the whole screen from camera, the crazy high image size(retina) is raping the GPU every frame.
Multiple effects on mobile could explode the battery if the OS doesn't halt.

However, if you do the post effect between OnPostRender and OnPreRender, you are doing effect before camera output, and no extra image read and write to GPU. Check your frame debugger, they don't lie.

 

Thanks for explaining the topic @Lu4e, it really helped me to understand.

 

Doesn't that defeat the purpose of batching? You split stuff up just so it re-combines them some other way later?

 

Unity refused to batch them anyway(see OP, drawcalls remain the same), so they are not combined.

If those are batched in one single drawcall, the app may runs more slowly, due to video memory bandwidth limit.

 

The best way to go about having too many objects is just what we used to do for older mobile phones, gather bunch of them and combine, so say every 100 objects in my case are combined in one draw call. That gives 1 draw call and around 20k tris. As these objects range from 60 tris to 300 tris.

That way, the camera would mostly show two combined objects at any given time. which is not bad, two draw calls and 40k Tris.

Thanks to all that contributed to this thread, it was a great help.
To summaries; new phones are not that much improved when it comes to playing intense games due to the heating factor. So just deal with new phones like the old ones, at the most iPhone 5.

 

I mean that you're splitting a big mesh into a bunch of small meshes in the hopes that Unity will then re-combine it into big meshes later. The vertex limits are there so that, in theory, the batching system doesn't waste time batching things where the cost is higher than the benefit.

I understand that the optimum throughput will be at different batch/vertex count ratios on different systems, and I have zero experience balancing that, hence the question about whether or not the above defeats the purpose.

Edit: Do the things being batched in this case move? If not I'd look at mesh combining. Then you get precise control over what gets combined.

 

50 draw calls is not good, even on an iphone 7. I recommend focusing your efforts there first and cut that number in half. You don't mention it in your original post, but did you override the 30fps default as well? If so, those draw calls will hurt you even more. Clearly sounds like throttling is kicking in.

 

Yeah, I agree with you too.

They are trees, so OP did the mesh combine, but the vertices might already excess limit.
Marking dense forest trees as static is not suggested from Unity, so we need "manual batching", which is still an annoying process.

And OP finally decided to balance them.

By the way, the quote below may explain this.