Search Unity

Turning on VSync actually got rid of VSync (is this normal)?

Discussion in 'General Graphics' started by TheSaviour, Mar 20, 2019.

  1. TheSaviour

    TheSaviour

    Joined:
    Apr 20, 2015
    Posts:
    45
    For a while now, the Android game I'm working on has been suffering from random hiccups here and there. I've used all kinds of optimization techniques: Locking the frame rate at 60, turning off VSync, using mobile shaders, using occlusion culling, static batching, light mapping, using low-vertex meshes and GPU instancing. But those hiccups won't go away. For the most part, the gameplay is very smooth (stays at 60 frames per second 98% of the time). The hiccups usually show up around every 1 or 2 minutes. A lot of the time, they're caused by random spikes of Gfx.WaitForPresent (I know, I know, just hear me out).

    Now a lot of the solutions online simply say that I have to turn off VSync if I want those Gfx spikes to go away. But like I said, I already tried that (by setting it to 'Don't sync' in the quality settings). But even if I did turn it off, the profiler showed that VSync was still there.

    case 3a.png

    For example, in the picture above, you can see that there is a lot of VSync and there's also a Gfx.WaitForPresent spike (although in this particular case, it didn't causes any stutter).

    Now, this is what the profiler window looked like after I set VSync to "Every V Blank" and removed the Application.targetFrameRate code (so it's no longer manually locked at 60 frames per second):

    Gfx.png

    The Gfx.WaitForPresent spikes are all over the place. HOWEVER, you can clearly see that there's no more VSync. Furthermore, I even noticed that the game didn't stutter anymore (although I have to run more tests to confirm this).

    So what's going on here? Why is it that setting VSync to "Don't sync" caused VSync to appear in the profiler and setting it to "Every V Blank" caused it to go away?
     
  2. Sh-Shahrabi

    Sh-Shahrabi

    Joined:
    Sep 28, 2018
    Posts:
    53
    Unity profiler is a bit confusing. I am not sure my info is completely correct, but here is how I understand it:
    The wait for present here could just mean that the commands for rendering can not be send because the GPU is still not finished rendering the previous job. So it just means you are waiting for other calculation to finish. This has nothing to do with Vsync. Vsync is when you wait to synchronize your frame rate, not when you have to. So this means you are having a cpu bubble.

    As for the spikes, how does your memory profiler look like? Spikes like these are typically caused by the heap manager doing things. Unity profiler doesn't show everything that happens on the CPU, it just shows the time of the samples it has collected, so whatever function it actually knows of. So if the System is doing something in the memory, you wont see it in the CPU profiler
     
  3. TheSaviour

    TheSaviour

    Joined:
    Apr 20, 2015
    Posts:
    45
    But how do you explain the fact that setting VSync to "Every V Blank" actually got rid of the VSync in the profiler?
     
  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    195
    This sounds like there might be some mislabeling of the VSync sample going on here.

    On one side, it is sadly the case that time spend in the GPU actually VSyncing is not always correctly attributed to that category. This might be platform and maybe even hardware specific. Please report these instances as bugs.

    Another side is that the Editor doesn’t VSync on the GPU and instead also uses WaitForTargetFPS to simulate the delay for VSync. That should, to my knowledge, not happen on device though. if it does, that would also be worthy of a bug report, at least so that someone with more knowledge on this than me can clarify and document this somewhere.

    Now, as to the issue of occasional frame drops: Assuming this is not an issue of thermal throttling (which, on a phone running at 60 FPS for 2 mins before it appears is a likely issue), this could be an issue of missing the VSync. You should look at this with the Timeline View and also look at the surrounding frames. Likely previous frames finished their rendering threads later and later until the one with the drop had to start so late and take so long that it missed a VSync. There might also be a dropped frame after that. However, that only really makes sense if VSync was actually a thing the GPU was doing and not really if it was just the CPU waiting to end the frame to delay it until it reaches the target frame rate...