Search Unity

  1. Unity 2017.2 beta is now available for download.
    Dismiss Notice
  2. Unity 2017.1 is now released.
    Dismiss Notice
  3. Introducing the Unity Essentials Packs! Find out more.
    Dismiss Notice
  4. Check out all the fixes for 5.6 on the patch releases page.
    Dismiss Notice
  5. Help us improve the editor usability and artist workflows. Join our discussion to provide your feedback.
    Dismiss Notice

BIG Performance Issue with Unity5 on Android !!!

Discussion in 'Android' started by cnzjnblxj, Jul 6, 2015.

  1. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
    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
    unity5-1.png
    unity5-2.png
    Below is the shader code of program=6
    unity5-3.png
    ----------------------------------------------------------------------
    The snapshots of Adreno Profiler below shows an empty scene built with Unity4 run on an android device
    unity4-1.png
    unity4-2.png
     
    nitroSS and MrEsquire like this.
  2. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
    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.
    unity5-4.png
    ---------------------------------------------------------------------
    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.
    unity4-3.png
     
    nitroSS, Mihai77 and MrEsquire like this.
  3. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
    upupup
     
  4. MrEsquire

    MrEsquire

    Joined:
    Nov 5, 2013
    Posts:
    2,629
  5. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
  6. MrEsquire

    MrEsquire

    Joined:
    Nov 5, 2013
    Posts:
    2,629
    Please be more specific, which version Unity 5 you using, I would suggest trying 5.1.1latestpatch
     
  7. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
    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.:(
     
  8. MrEsquire

    MrEsquire

    Joined:
    Nov 5, 2013
    Posts:
    2,629
    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 :)
     
  9. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
    no luck :(
     
  10. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    Can you submit this as a bug report with a reference to this thread?
     
  11. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
    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.
     
  12. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    Done: (Case 710822)
     
  13. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    The additional blit from an FBO to the back buffer was added in Unity 5/Android.
    It was done for various reasons (workaround for buggy compositors/allows alpha in frame buffer, workaround for buggy hardware scalers, better/working MSAA switching at runtime, multi-display, better match to Unity scripting APIs like Display, allows read access to backbuffer which is needed for some Unity scripting APIs).
    The costs of the blit is between 0.5ms-2ms in our measurements, depending on rendering resolution and GPU. Of course it also costs some power.
    We are considering making a "fast path" for cases where we can do without the extra blit, but that probably won't come with a patch-release.
     
  14. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    19,657
    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.
     
  15. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    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)
     
  16. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    I don't think you can just add time deltas of stuff that's running on the CPU (scripts, physics) to stuff that's running on the GPU (blit).
    Obviously an additional copy is not an optimal solution and if you are GPU limited then the blit is wasting 0.5-2ms of your frame time + memory bandwidth and power. But so far I have not seen a case where it would cause even close to 30-50% slowdown as reported in other threads.
    The cost of the blit isn't necessarily cheaper on new devices with faster GPUs because these tend to have very high resolution displays and the mobile GPUs usually get more ALU power and not so much additional bandwidth.

    To render at a lower resolution you can always use Screen.SetResolution. Especially on 1440p phones that's probably always a good idea. We are thinking about adding a GUI option to the PlayerSettings or QualitySettings, maybe depending on the screen DPI, but that's not decided yet.
     
  17. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    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.
     
  18. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    Afaik "WaitForTargetFPS" (name in Unity Profiler) blocks the Unity main thread.
    "Graphics.PresentAndSync" is blit + SwapBuffers and SwapBuffers may block when limited by the GPU or display refresh rate. Other graphics API calls may also block for the same reasons (e.g. Clear).
    The wait for the actual vblank is somewhere in the compositor, check https://source.android.com/devices/graphics/architecture.html.

    The value of Present.BlitToCurrentFB isn't very helpful because it only measures the wall time for the API calls, no sure why we have it. We measured the cost by comparing the frame times of same (non-empty) scene with and without the blit.
     
  19. cnzjnblxj

    cnzjnblxj

    Joined:
    Jul 6, 2015
    Posts:
    14
    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.
     
  20. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    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?
     
  21. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    Yes there might be a way to avoid the blit in future versions, but it's not decided yet.
    And yes, adding a checkbox to the PlayerSettings would be the easiest solution but there are still some cases and devices where a blit is always preferred so we would have to figure something out that is not too confusing ;).
     
  22. noetic_wxb

    noetic_wxb

    Joined:
    Mar 4, 2015
    Posts:
    2
    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.
     
    Jonny-Roy and MrEsquire like this.
  23. Rusfighter

    Rusfighter

    Joined:
    Jan 18, 2014
    Posts:
    60
    Is there any progress about disabling this "blit feature" in unity, or anything else related to this topic?
     
  24. albertus88

    albertus88

    Joined:
    Sep 23, 2015
    Posts:
    1
    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.
    Captura de pantalla 2015-11-11 a las 15.55.06.png

    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!!
     
    Jonny-Roy and MrEsquire like this.
  25. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    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.
     
    albertus88 likes this.
  26. ChiuanWei

    ChiuanWei

    Joined:
    Jan 29, 2012
    Posts:
    74
    so the Image Effect if using the rendertotexture will cause twice as expensive on Android now?
     
  27. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    Compared to Unity 4 they are... well for a simple effect they are.
     
  28. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    Currently it should be exactly one additional blit per frame and does not depend on if you are using ImageEffects or how many ImageEffects you are using.

    Regarding the numbers from the Tegra Debugger, can you describe what's actually happening in the scene? 6ms is definitely too much. In case this is an almost empty scene it could be that the GPU is running at a lower clock frequency.
     
  29. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    If you are only using 1 rendertarget as in:

    Code (CSharp):
    1.     {
    2.         // Check if we have a camera before rendering
    3.         if (viewPortRT)
    4.         {
    5.            
    6.             MainCamera.Render();          
    7.  
    8.             Graphics.Blit(viewPortRT, destination, mat);
    9.         }
    10.     }
    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.
     
  30. SurfDog

    SurfDog

    Joined:
    Apr 28, 2016
    Posts:
    2
    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).
     
    Jonny-Roy likes this.
  31. Brian-Kehrer

    Brian-Kehrer

    Joined:
    Nov 7, 2006
    Posts:
    409
    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.
     
  32. macrod

    macrod

    Joined:
    Dec 9, 2012
    Posts:
    6
    If I assign a RenderTexture to Camera.targetTexture and do Graphics.Blit(rt, null as RenderTexture) in OnPostRender(), do I just get one Blit?
     
    Last edited: May 12, 2017
  33. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    No you still get 2, see my post above highlighting this, you get 1 additional blit no matter what you do.
     
  34. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    4,122
    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.
     
  35. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    Someone is actually working on making this configurable.
     
    Jonny-Roy and AcidArrow like this.
  36. macrod

    macrod

    Joined:
    Dec 9, 2012
    Posts:
    6
    It's important for me to avoid the built-in RenderTexture + Blit if assigning RenderTexture to Camera.targetTexture.
    Thanks!
     
  37. seppo

    seppo

    Joined:
    Jun 3, 2017
    Posts:
    2
    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?
     
    Jonny-Roy likes this.
  38. _watcher_

    _watcher_

    Joined:
    Nov 7, 2014
    Posts:
    61
    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):
    empty-scene-android-perf.jpg

    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).
     
    Last edited: Jun 7, 2017
  39. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    It's planned for 2017.2, but it's not done yet. So no guarantee.

    We don't have any plans to backport this to 5.6.
     
  40. seppo

    seppo

    Joined:
    Jun 3, 2017
    Posts:
    2
    Thanks for the info!

    Cheers,
    Jani
     
  41. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    174
    Some news on this, Unity 2017.2 will have an option to disable the additional blit without fallback. So you have to know what you are doing.
    Initially we had a plan to add another "automatic" option that would only use the blit when it is needed (e.g. when using linear rendering), but that wasn't ready yet.
     
  42. _watcher_

    _watcher_

    Joined:
    Nov 7, 2014
    Posts:
    61
    Thank you for the news, much appreciated!!!
     
  43. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    4,122
    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.
     
  44. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    4,122
    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!
     
  45. Jonny-Roy

    Jonny-Roy

    Joined:
    May 29, 2013
    Posts:
    660
    Awesome, is it just a checkbox option? I've not downloaded the Beta yet.
     
  46. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    4,122
    It's a drop down in player settings which has two options.
     
    Jonny-Roy likes this.