BIG Performance Issue with Unity5 on Android !!!

Hello, I think there is a performance issue in Unity5 when run on Android devices.
I build an apk with just an empty scene, and I use Adreno Profiler to see the drawcalls.
Then I find Unity5 first draws all the things into an render texture, then uses a single drawcall to blit the render texture to the back buffer.
This causes the Pixel Fill Rate really high, and this behaviour didn't exist in Unity4.6 with all mobile platforms or Unity5 with iOS.
I want to know if it's a bug or not. Such a heavy blit operation is really a great big cost on mobile devices. Is it possible to use the behaviour in Unity4.6?
Thanks

The two snapshots of Adreno Profiler below shows an empty scene built with Unity5 run on an android device


Below is the shader code of program=6

----------------------------------------------------------------------
The snapshots of Adreno Profiler below shows an empty scene built with Unity4 run on an android device

 

Below shows the stats of gpu while running the app built with Unity5. You can see the FPS is about 30, GPU Clock is about 450MHz, GPU busy is about 11%, and Fragments Shaded per Second is about 60M.
My device has a resolution of 1920x1080, that is about 2M pixels, and since FPS is 30, so the Fragments Shaded per Second is 60M just make sence.

---------------------------------------------------------------------
Below shows the stats of gpu while running the app built with Unity4. You can see the FPS is about 30, GPU Clock is about 450MHz, GPU busy is only about 4%, and Fragments Shaded per Second is about 0.4M.
It seems there is really no BLIT in Unity4.

 

upupup

 

Excellent post and proof!!

See this thread http://forum.unity3d.com/threads/very-poor-performance-on-android-after-upgrading-to-unity-5.306572/

Everyone having issues and no proper fix yet and we on 5.2Beta!!

 

I also find an issue on the Issue Tracker maybe related with my problem, the link is here:
http://issuetracker.unity3d.com/iss...channel-is-always-set-to-1-on-android-devices

If this is how Unity5 fix the issue above, I hope they can give us a setting to avoid the final blit operation which like Unity4.6 does.

 

Please be more specific, which version Unity 5 you using, I would suggest trying 5.1.1latestpatch

 

Thanks for your suggestion.
Our current version is 5.1.0f3. I'll try the latest patch version tomorrow, and I hope the problem has been solved already.

 

I hope also, but its best to always check on latest version as it saves us time later when debugging and helps make sure Unity devs know if it fix or not...Thanks for the detailed report

 

no luck

 

Can you submit this as a bug report with a reference to this thread?

 

Something wrong with my unity, and I can't submit a bug report.
Could you please do me a favour, submit a bug report to unity and reference to this thread. Thanks a lot.

 

Done: (Case 710822)

 

Yes it probably would be best, given it's mobile and a vast amount of customers are just making 2D titles for mobile. What if one wants to do their own final blit regardless for their own scaling? We did this for many mobile titles, and in addition do it on a custom mesh for additional special effects.

I would also advocate an advanced mode for all platforms really - wherever we want to take responsibility in exchange for some speed back

0.5-2ms is high on mobile, it's a screen worth of parallax or non overlapping particles.

 

Could it not be one of the explainations people are reporting slower performance on Android in Unity 5?

I mean one issue I often see is if you have a Physics update of 0.02, then you have to be under 20ms on android due to the forced vsync in release otherwise you will get 2 fixed updates per-frame, so assuming your Physics and Scripts take 10ms on a slow devices + your 2ms from above (assuming you tested bottom end devices) that leaves less than 8ms for the graphics, if you go over this 8ms, your essentially dropping the framerate to half!

It does seam in Unity 5 to be a lot stricter on hitting the spot that gets smooth performance on low end hardware, I find going over. Also given you are doing this Blit, how come we don't get the option to render as lower resolutions to make up for the loss (like the performance settings in iOS)

 

But isn't the Wait for sync done on the CPU side, so if your hitting the point where you miss the sync on the GPU you have to wait for the next one before draw happens, meaning a wait on the CPU thus reducing the framerate dramatically, at least thats what seams to be the case on my test device with a Mali-400, as I get better performance without V-Sync. This device doesn't support Screen.SetResolution, so you can't drop the resolution to gain performance.

Though to be fair, is the time taken by the blit operation Present.BlitToCurrentFB? If so thats not the cause of the drop I'm seeing between 4/5 I think it might be the change in batching algorithm.

 

Thanks for your reply. Do you mean in the future version of Unity5, the render pipeline may remove the extra blit if it is not needed? Or will you export a setting to let users to decide whether they need the extra blit? I think the second solution may be easy to implement and more flexible.

 

So doing some math if the 2ms at worst is correct:

Old FPS MS Req With Blit New FPS
50.0 20.0 22.0 45.5
30.0 33.3 35.3 28.3
20.0 50.0 52.0 19.2

So at the top end of performance it does create quite a drop might be an issue for VR apps needing the high rate, at the bottom end though not too much a problem, if 2ms is accurate.

It would probably be a big problem if you wanted to use RenderTextures for post processing effects though, would be good if you could expose the RT to us before it is output in some way, or even the shader used in the Blit?

 

I found this issue too. it's confuse me until i found this post.
I think we imminently need a API to directly render to back buffer.In China and India, there are so many devices with big screen but poor memory/CPU/GPU . These devices are only cost 50~100 $. But hundreds of millions people use these devices and play games.
And i also think, set lower resolution option is a bad idea. Yes, we need low resolution to improve performance. But only 3D Object render to lower resolution FBO. The UI need to render to higher. So this should config by programmer. A article or demo maybe better.

 

Is there any progress about disabling this "blit feature" in unity, or anything else related to this topic?

 

Hey! It's my first post in this forum.

I have a problem with the performance of my game in Android devices, I have read all posts, and I think that I have the same problem.


The frame debugger is Nvidia Tegra Debugger and the device is Nexus 9.
As you can see, The Event 4558 is a draw in a frame buffer, but I don't use a renderTarget in my game.

And the time is 6.3 msec extras in each frame.

I'm using Unity 5.2.2p3.

Could you help me to fix please ??

Thank you!!

 

Can you comment on the above post? I'm also seeing that if you render to a rendertexture it does in fact re-blit again, meaning render effects become twice as expensive.

 

so the Image Effect if using the rendertotexture will cause twice as expensive on Android now?

 

Compared to Unity 4 they are... well for a simple effect they are.

 

If you are only using 1 rendertarget as in:

Code (CSharp):

1.     void OnRenderImage(RenderTexture source, RenderTexture destination)
2.     {
3.         // Check if we have a camera before rendering
4.         if (viewPortRT)
5.         {
6.            
7.             MainCamera.Render();          
8.  
9.             Graphics.Blit(viewPortRT, destination, mat);
10.         }
11.     }

Where MainCamera is set to render to viewPortRT, then Unity ends up doing an additional unnecessary Blit after this one, so thats what I mean by you end up with 2 blits instead of one, number of effects would be irrelevant, as anyone with sense with combine them into 1 shader! But yes for the standard unmodified ones, Unity only adds one additional...unnecessary Blit.

 

Are there any more news on this "extra blit"? Is there now a way to disable it?

@florianpenzkofer did you get an answer to "what is happening in the scene"? Based on my own experience with TGD, it looks like a "typical game frame", with ~4,000 OpenGL calls, which typically represents roughly 400 DrawCalls from Unity. And the very last DrawCall is a full-screen triangle which takes over 6,000 microseconds. Yes, over 6ms for the "extra blit". I do not see any indication that GPU is being throttled (previous draw call is only 35us).

So yes, in this case (and in my own tests), we could save up to 6ms per frame if we could disable that "extra blit"!

Note that for a VR title, that could be a difference between enjoying the game and getting sick (i.e. not being able to play the game).

 

I'm also waiting for a main-line fix for this. It's consuming between 3-4ms of frame time on high pixel density devices, when we need to be at 60fps.

 

If I assign a RenderTexture to Camera.targetTexture and do Graphics.Blit(rt, null as RenderTexture) in OnPostRender(), do I just get one Blit?

 

No you still get 2, see my post above highlighting this, you get 1 additional blit no matter what you do.

 

This is the kind of thing that should be a checkbox, so we can disable it. In cases like this, you need to inform us better, let us know of issues and hint at ways to fix them, instead of making everyone's performance worse.

Implementing a workaround for something, that makes everything slower and then putting it in a black box where we have no access to is most defenitely the wrong way to do things.

The extra blit is still there and it's annoying.

But I'm guess this, is yet again, another thing that will be able to fixed once we get "proper" scriptable render loops... They can't come soon enough.

 

It's important for me to avoid the built-in RenderTexture + Blit if assigning RenderTexture to Camera.targetTexture.
Thanks!

 

What's the timeline for fixing this?

Ever since our project (live game) got updated to Unity 5, I've been waiting for some fix for this. It's super annoying that there are no options for controlling this. Our game runs on all custom shaders and we don't use destination alpha for anything.

We are currently looking into updating from 5.3.4p1 to 5.6.1, but if the fix for this is just around the corner (say 2017 release), we would possibly wait for that instead of switching to 5.6.1 (which is going to cause a full send of all asset bundles).

Any info on whether this will be something done in 2017 release or will it also be added to 5.6 patch or minor releases?

 

Hey! What seems like the same problem here. I'll report my setup and give you a Profiler screen.

Tablet specs:
hw: Lenovo TAB 2 A8-50LC
os: Android 5.0.2

Unity project setup:
- empty project (5.6.0f3, 2D, no analytics, no packages imported)
- new scene (removed camera)

Profiler (16.31ms eaten by Graphics.PresentAndSync, of which 12.66ms is Present.BlitToCurrentFB):


I've released 1 Android game so far, but with this kind of performance overhead in empty scene, there is really no way for me to work on any major Android project. 60fps is impossible in an empty scene.

PS: Windows build of the above on i5-3570K @ 3.4GHz runs at ~4000fps).

 

Thanks for the info!

Cheers,
Jani

 

Thank you for the news, much appreciated!!!

 

Seems like the feature made it in 2017.2 betas. Did anyone try it?

I tried to try it but I can't build my project. For some reason the beta crashes when I try to build.

 

So, good news, I managed to build and it seems like this issue is fixed in 2017.2.

The performance/power difference in my case is significant enough, that my test devices don't throttle any more which used to bring my performance all the way down to 30fps, but now it keeps steady to 60fps, yay!

 

Awesome, is it just a checkbox option? I've not downloaded the Beta yet.

 

It's a drop down in player settings which has two options.

 

Are you supposed to just select "AndroidBlitType.Never" without anything else in camera scripting? I just get a black screen when using "Never" or "Auto".

 

my question is about if you are supposed to do something else, like manuall blit or smth. in order to get it to work, because i only get a black screen when i using this setting.

EDIT: Maybe it is just a bug:
https://issuetracker.unity3d.com/is...o-or-never-causes-android-to-show-black-scene

 

Yeah it has been bugged in the last few releases...

 

Has this been fixed? Still getting a black screen but the issue tracker says "Fixed in future release"