Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Bug Build of very simple project has extreme idle time

Discussion in '2020.1 Beta' started by Slaktus, May 24, 2020.

  1. Slaktus

    Slaktus

    Joined:
    Dec 5, 2012
    Posts:
    58
    Got a simple project that simply spawns 100,000 unlit cubes and moves them in a random direction at constant velocity from the center of the screen. When the cube leaves the screen, it is destroyed and a new one is added to the center of the screen with a random velocity.

    The test runs fine in the editor:
    upload_2020-5-24_20-34-58.png

    But when I build it, the framerate drops precipitously thanks to several frames worth of idle time between scripts and rendering:
    upload_2020-5-24_20-36-15.png

    Any idea what might be causing this?

    Running Unity 2020.1.0b7.3556, using Hybrid Renderer V2, Burst 1.3.0-preview.9 (Current), Entities 0.10.0-preview.6, URP 9.0.0-preview.14 (Current), Hybrid Renderer 0.5.0-preview.6 (Current).

    Happy to post project.
     
  2. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,127
    Thanks for bringing this up. Could you please submit a bug report with the project attached for this issue so we can have a look?
     
    Peter77 likes this.
  3. Slaktus

    Slaktus

    Joined:
    Dec 5, 2012
    Posts:
    58
    Last edited by a moderator: Jun 4, 2020
    Peter77 and LeonhardP like this.
  4. Slaktus

    Slaktus

    Joined:
    Dec 5, 2012
    Posts:
    58
    @LeonhardP @Peter77 I just received an email about this from your one of your QA people, who said that it was because of vsync.

    That's not the case. I tried disabling vsync from settings, from code and even from drivers, and in any case the wait for target FPS spans multiple frames no matter the workload and vsync settings. This is what the profiler looks like when profiling a development build with vsync disabled:

    upload_2020-6-25_22-25-13.png


    As you can see, the actual work being done fits comfortably in 16ms, but for some reason there's a lot of waiting.

    Should I submit the bug again?
     
  5. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,406
    You can just reply with your findings of what happens with vSync turned off, that will reopen the existing one.

    However, what resolution are you running this on in the Editor vs the player? You could be GPU / fill rate bound. Try running both at the same resolution to compare them in a more representative way. Also, are both the editor and the player using the same Graphics API? Have you tried the GPU Profiler with this, or if that's not feasible, a platform/GPU chip-specific profiler, e.g. vTune?

    The CPU Usage Profiler only shows CPU timings. As explained in the Profiler documentation for such common samples, Gfx.Present can mean it's waiting for VSync, or just for the GPU to finish drawing. As such, we can't just conclude that the work would fit into 16ms because we're not seeing all the stuff that is being worked on.

    Also, we are painfully aware at the unfortunately sparse covering of GPU Profiling capabilities across Graphics APIs, platforms and configurations and the therefore lacking visibility and incomplete workflows in the Profiling offering and are working towards closing those gaps.
     
    Last edited: Jun 27, 2020
  6. Slaktus

    Slaktus

    Joined:
    Dec 5, 2012
    Posts:
    58
    Hey,

    I feel pretty sure I'm not GPU or fillrate bound since I'm running this on a desktop computer with an 8GB AMD RX580.

    When I get time I'll deploy the project for PlayStation 4 and use the Razor GPU profiler to get a better picture of what's going on.

    Oh, and a reminder that the slowdown only happens when I'm running a BUILD. The performance is totally fine in the editor, regardless of viewport resolution. I can run it totally fine in fullscreen from the editor, where performance is usually significantly worse than in builds.
     
  7. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,571
    A simple way to test this is to run the game at a very low resolution. I run my tests at 320x240 for example, to avoid being GPU bound.
     
    MartinTilo likes this.
  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,406
    Thanks, that information was missing here and in the bug report so far. I was going by the screenshot at the top of this thread which shows a very small game view being profiled.
    But yes, just to make certain, I'd set a fixed resolution in both editor and build, try windowed and fullscreen, and check again that the same Graphics API is used (set in the Player settings, if there's multiple set and auto selection on the build could choose a different one than the editor.) Also the build might be using different QualitySettings?
    If all that is isolated out and there's still a significant difference, please respond to the bug with this additional info to reopen it.