Based on the Unity Diagnosing Performance article disabling the VSync seems like a good practice while profiling the game.
My question is: If I use VSync in my project (ProjectSettings/Quality/VSync Count), I NEVER see the WaitForTargetFPS function in the Profiler.
Why?
The question is, what ARE you seeing? It could be that the vSync is happening on the GPU so you’d see it as Gfx.WaitForPresent (or Gfx.WaitForPresentOnRenderThread)
Also, are you profiling Playmode or a built player? And if Playmode, have you checked in the game view’s resolution/aspect ratio drop-down if it is set to vSync?
Thank you Martin for your reply.
I’m profiling in Playmode and yes, the cSync flag is set to TRUE in the ratio drop-down
I see Gfx.WaitForPresentOnGfxThread on the GPU side, BUT it is spending NO time (0ms)… is it normal?
Do you mean in the GPU Profiler? This marker would be relevant on the main thread of the CPU Profiler.
Martin, thank you again for your reply.
Let’s make it clear: The only task that begins with “WaitForP” is present both in CPU and in GPU profiler, and is taking no time to accomplish (0%). Here you can find my CPU profiler (there is no trace of a VSync graph, even if I enable only the VSync flag) and my GPU profiler.
How can I see the impact of VSync, if I always see 0% in these tasks?
The sample being present on both doesn’t mean it is actually significant on both, sorry for that confusion, but this sample is only significant on the CPU side. I’ll look into this if we can’t filter these out on the GPU side…
So to be honest, I’m not exactly sure how/where the game view vSync is implement. (I’d need to check this aftet my vacation) so it might be a sample in the EditorLoop or just some other sample. Also, sadly not all VSync is properly attributed to the VSync category (yellow in the graph). E.g. depending on platform, graphics API and editor vs player, it might be implemented differently and e.g. sync on the GPU as part of Gfx.Present and can’t be separated out from the remaining GPU calculations for Present.
Now for the frames where your CPU time hits an increment of the vSync time, I’d assume something is enforcing the vSync proper but, since I don’t know exactly how the game view vSync is implemented, I don’t know under which sample. That’d be something to search for.
Looking at timeline view might also help to understand this. It could be that game view vSync just makes sure that you don’t drop below 16.66ms but allows the remaining editor code executing around the player loop to take longer and not also have to wait for the vSync to stat the next loop.
Now in general though, the performance behavior in the Editor (Playmode) is not representative for your game’s performance because there’s just too much stuff happening on the side that can interfere. If you build a development player and profiled that, you should be seeing those samples and see the CPU time clip to increments of the vSync time.