Question why does the Gfx.presentFrame has a long-short patern in profling timeline

hi, I am doing profiling on my android device, my phone is an old model released around 2017 , and the player camera is in idle statues , no any interaction and camera view change .

from the profiling data , it seems take long time on render thread all the time, but I am confused about the Gfx.presentFrame (marked with green line ) has a long-short pattern, one frame takes 27ms ,but next frame it goes down to 2.07ms. Comparing with it , the ScritableRender.execute:UniverslRenderPipelineAsset_Render in the render thread seems stable , always consume 20+ms to send command to GPU.

if the GPU is doing the heavy work, then why Gfx.presentFrame can be super faster in one frame suddenly, then slow back again ? there is no any change in the playercamera view during this time.

I am wondering if this is a GPU bottleneck or plus Vsync issue ? can anyone help to explain it in details , thanks .

 

since my camera is static and no any player operation to trigger animation/VFX , the CPU may has to deal some network or GC but the GPU content should be all the same in each frame rendering,

so I am guessing if this is due to the combination of (GPU async with CPU ) + (GPU Vsync with the Screen)

this is the rough guessing based on my above understanding, hope people can recorrect me if this is not the truth

 

It's related to vsync. Essentially if your frame takes too long to process and cannot get done in time for the current vblank it has to wait around for the next, effectively halving your framerate for that frame at least.

 

@Sluggy, thanks for your replay.
so basically, the GPU may not be the only bottleneck, the Vsync missing maybe due to the combination of CPU and GPU all together. in my situation, at the shorter frame, from the render thread start to the end of the presentFrame, this time range might be the real GPU rendering time, I guess.

 

The longer wait frame is essentially just the time it takes to copy the frame buffer to the screen. All of the work for that frame was effectively done the frame before but because it wasn't done in time for the vblank it has to just spin in place while it waits for the next vblank. The easiest way to fix this would simply be to disable vsync. It's generally not as important these days with LCD monitors as it was back in the era of the CRT. If you really cant or dont want to disable vsync then the next easiest thing would be to lock the framerate to the refresh rate of the monitor divided by 2. This is still effectively halving your framerate but at least it's a stable frame rate now. And finally the obviously hardest thing to do would be to optimize your game so that it can a simulate and render a full frame in less time than the refresh rate (assuming a standard rate of 60hz, that means about 16 ms per frame or less)

 

@Sluggy my project target platform is mobile, either android or iOS cannot disable the V-sync I think.