Gfx.waitforpresent Taking 80ms When Gpu Is Finished In 7ms?

That looks like a curious case.
But first off, something from an upcoming change to the documentation regarding the Gfx.WaitForPresent sample that might shed some light on this:

"Gfx.WaitForPresent: When the main thread is ready to start rendering the next frame, but the render thread has not finished waiting on the GPU to Present the frame. This might indicate that your game is GPU bound. Look at the Timeline view to see if the render thread is simultaneously spending time in Gfx.PresentFrame. If the render thread is still spending time in Camera.Render, your game is CPU bound and e.g. spending too much time sending draw calls/textures to the GPU."

Camera.Render here takes 3.34 ms on the main thread. Hierarchy view only shows the main thread, so maybe a look at CPU Usage's Timeline View might shed some light on the render thread and the timings of those two threads.

If the render thread is not spending time on rendering but in Gfx.PresentFrame, that can usually mean one of two things:

1. You're GPU bound, which from the 7ms spend on the GPU does not appear to be the case.
2. The GPU is waiting for a V Blank to V Sync. With this high of a wait time, it would appear that your QualitySettings.vSyncCount is maybe set to sync less often than every VBlank and instead every 2nd, 3rd or even 4th?

Aside from that, maybe it's something specific to that phone & GPU? What Phone is that and does the same happen on other phones?

 

Ok, good to hear you made some inroads to solving the issue.
Having the GPU Profiler Module (the Chart in the window) enabled adds quite some overhead due to the way it works. If you want to get a better overall understanding of the performance and can infer the GPU side a bit, maybe also by toggling what you're drawing from within the build, you could get more accurate measures by closing the GPU Usage module before you start profiling.

As a side note, also make sure to not build the player with "Script Debugging" enabled as that will slow down the script execution by adding hooks all over the code for a debugger to hook into the running code. (Other profiler modules can also come with an overhead as should be visible in the Profiler under the Profiler.CollectEditorStats Sample. Closing modules you don't need will get rid of that overhead)

As for the remaining issue of switching back and forth between fps levels, that kind of sounds like the phone might periodically switch into a throttling mode. Sadly, Unity's profiler is currently unable to show you stats such as core speeds, battery and heat levels. There might be platform profilers that can shed some more light on this. This manual page lists some relevant ones and the category it is in might also contain relevant info.

 

Are you using particles with shadows enabled? If so, try disabling shadows for them.

However, this should just be a higher GPU workload pushing the frame time. Shadows can be expensive.

 

@paradizIsCool so it was not particle related but just shadows on vs shadows of? Could it be OpenGL related?
s5 mini runs OpenGL 3, Huawei p8 lite runs 3.1 If I'm not mistaken.
Have you tried switching to Vulkan?

Also, what's the bug ID?

 

Hello @byton,
Just from looking at screenshots I can not tell if this is the same issue or not. Since it is another project, and a more complex one than just 12 cubes (presumably) that would be comparing apples to oranges.

Performance differences between Mac/PC Standalone and mobile can have a whole array of causes, not least of which that the entire GPU architecture is a different one and heat throttling a thing. So, let's please keep these separated for now until our QA can make a more thorough determination if this is indeed the same issue.

On that note, @byton: please report a bug. The forum is not a bug tracker and reporting/tracking bugs on the forum problematic for a whole bunch of reasons. Your best shot at having your bug fixed in a timely fashion is to fill out a well written bug report with clear reproduction steps.

In your bug report, please do link to this thread and give the bug ID to the potential duplicate

1193733

and then post your bug's id here as well.
That way QA can make a proper determination and find a reproduction faster , as well as that it provides more info to the devs who are going to fix this later (not me, I work on the Profiler, which is just the messenger here so please don't shoot me ).

I don't think so. The WaitFor* samples are rather generic and a bad metric to use when searching for a solution or comparable "bugs". ("Bugs" because more often then not, this is just about the workload being thrown at the GPU)
I've seen the bug in the first thread first hand and your screenshots contain info that distinguishes them from that bug. I.e.: No Canvas.BuildBatch and you don't appear to have anything synch fencing on the first opportunity within the frame (though it's kind cut off in that screenshot of yours)
The second thread could be related in the sense that maybe you're just giving the GPU too much work to do. On that note:

For Mobile, you should consider using the mobile shaders instead of the standard shaders. I'm not firm enough with URP to know how it is there, but in the pre-SRP renderer, the standard shaders did not perform great on mobile (once again, different GPU architecture, tilebased-rendering and such).

To drill down deeper on your project, try bulding with the auto connect Profiler option and the GPU profiler module open before you start the game on your phone. Give it some tries. Starting up the GPU profiler is sadly not as stable as we'd like and if no data is comming in, we erroneously assume that it just doesn't work on your device (we're working to improve that). If it really doesn't work, check out RenderDoc and other mobile profilers (E.g. ARM's tools, in you're case Qualcomm's or XCode's instruments if the same happens on iOS) and use that to determine what is impacting your performance that badly.

Sidenote, also @paradizIsCool: It appears as though QA has a hard time reproducing this on any hardware they found so far, they are still looking to find a Huaweii P8, I'll make a note that maybe xiaomi redmi note 4 would also have this issue, though an additional bug report would still be far more valuable. If you, @paradizIsCool, can repro this on any other device as well, please reply to the bug to let our QA know.

 

Metal ist currently not supported by Unity's GPU Profiler. Try using XCode's Instruments to get some GPU measurements. Also might be worth posting this as a separate Topic under Platforms/OSX or Graphics/General Graphics as it seems like it's own thing.