As you can see on the Frame Debug,there is only Clear(color+z+stencil) and nothing else on RenderForwardOpaque.Render but on the profiler it is the slowest.
The Camera Flags is set to “Solid Color” and when I click on Clear in the Frame Debug only the camera with the background color is shown.
I don’t know if it is a bug on the profiler because PostLateUpdate.FinishFrameRendering takes 90% of the GPU and a big chunk of the CPU(50-60%).
This is the PostLateUpdate.FinishFrameRendering on the CPU:
I don’t understand if the problem is on the GPU(it is a very simple scene) or the CPU but from what I read on different threads it seems that the CPU is waiting for the GPU with Semaphore.WaitForSignal.
The game has an average of 60FPS but I don’t understand why RenderForwardOpaque.Render/Clear is taking so long on the GPU with nothing to render except Clear.
As stated in the other thread you posted to, not an area I’m too knowledgeable in but: if you’re at 60 FPS, I don’t see the problem and could even guess that it can’t clear because the last frame is still being presented. Mobile device tend to be hard capped at 60 FPS by the OS/hardware to not burn through the battery in seconds.
If that’s the case, clear, just like WaitForSignal, isn’t actually taking up any GPU/CPU cycles and instead just waiting. I could be wrong though.
If you want to get some more details, you might want to try arm’s profiler tools like Streamline or Graphics analyser.
I’ve faced with the same issue. Very simple scene, but PostLateUpdate.FinishFrameRendering takes 150-250ms on RenderManager.DoRenderLoop_Internal()
Unity 2019.3.15f with default URP
The spike is from when I enable/disable the main camera to the UI camera (when entering the game menu).
Again as OP says, avg 60 FPS, Semaphore.WaitForSignal taking up the CPU.
From what I’ve been reading it seems the CPU isn’t actually being used, but rather, is waiting for something, therefore the profiler shouldn’t be giving these misleading stats.
Also worth noting that screen shot is from build, while in editor, the spikes are no bigger than 9ms…
Dont’cha just love debugging!
As much as it pains me to do so, I’m going with Martin and just accepting the 60fps and marking this as a HDRP profiler issue (that I don’t fully understand).
