I’m not sure what else to do now. Im profiling on my android device and the GPU cycle is taking ~7ms while total time is 80ms+ with Gfx.WaitForPresent taking 79ms and I am getting extremely low fps. I’ve tried so many threads and solutions that I think it is better for me to ask again…
Using 2018.3.11
Thanks for the help.
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:
Aside from that, maybe it’s something specific to that phone & GPU? What Phone is that and does the same happen on other phones?
Thanks for the hints MartinTilo.
Most important info in case someone comes here: Phone model is Huawei Honor 10. Pretty new/decent phone I would think. I tested the scene on a Google Pixel 3 and it runs smoothly but it has no GPU profiler option and it is a better overall phone.
I took a look at the Render Thread and found it’s using 45+ ms in GpuProfiler.EndQueries. Running the game when unplugged from the computer and thus debugger significantly increases my fps… but now I can not profile it and the fps is still not 60, its switches from 30-45 fps every couple seconds. But I would like to profile it to figure out where I can increase my fps and why its switching fps so drastically every ~5s without changes to the scene.
Other things to note from Profiler, the Camera.Render in the render thread is taking ~15ms and Gfx.PresentFrame is taking ~4ms so I guess it is CPU Bound according to what you said and I would have to try to get less draw calls sent to the GPU.
I initially tried all different settings of Vsync with no luck.
More information as I have been at this for too long… I found the only object in the scene that causes any change in fps is the Terrain. It is a small flat terrain with some brick texture drawn on it. I did some more digging and people recommend not to use a terrain in mobile, and I have taken it out and replaced it with a plane with a material and my game now runs smoothly, although I still have ~9ms taken by GpuProfiler.EndQueries.
Honestly I would like to try to optimize the scene with terrain and profiler attached but I have such an easy solution to just drop terrain completely and I don’t know where to continue with debugging my original problems.
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.
Hi, I have similar issue on Huawei p8 lite, it spends a lot of time in Gfx.PresentFrame. Without shadow it’s ok, we’re still at 60 fps, with shadows it takes much more time in wait, but not in render phases.
after/before
without shadow
with shadows
The little task that stops GFX.PresentCommands is Present.SecondarySurfaces.
Unlocking vsync and targetframerate doesn’t change anything.
Very simple scene, 4 objects, 1 plane for ground, 2 particles and UI in screen space - camera.
Really don’t know what I can do to avoid that
Unity 2018.4.9
Tested on s5 mini, no issue
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.
Made a sample project with 12 cubes, same story, 30fps with a lot of waiting. Bug reported
@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?
bug Id: 1193733
Just tried with vulkan, it’s worst, 100ms per frame, 93ms of waiting
Unity 2020.1.0a11 URP
Unity 2019.2.1f1 LWRP
Unity 2019.3.0b3 LWRP
Same problem on all of this versions for android xiaomi redmi note 4.
I think its the same problems:
Extremely slow editor in 2019.2.0a7 page-3#post-5047931
Gfx.PresentFrame and Gfx.WaitForPresent in the same frame
Please fix this terrible bug!
This is a profiler screenshot. I recorded the data offline from the android through the Profiler class. Each PresentFrame takes 20 milliseconds. Sometimes he eats 50 or more!
Application.targetFrameRate = 60;
QualitySettings.vSyncCount = 0;
We have no chance to do something with URP on android. on PC this wort perfectly.
Unity 2020.1.0a11 URP
We moved our project to a standard render and got better! We hung the usual standard shader on all objects and now the same game works at 50 fps, instead of 25-30 on URP for android.
Please fix it!
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.
Unfortunately, no 
I’m experiencing something that looks very similar to the above at the moment, via Unity 2019.2.17f1 running on macOS.
Unfortunately my hardware doesn’t support GPU profiling so it’s difficult to dig any further, but it doesn’t appear that we’re GPU bound nor CPU bound – though possibly is a timing/bandwidth related issue as the project does make substantial use of ComputeBuffers and pausing the ComputeBuffer stream temporarily does seem to alleviate the issue.
Notably, the same exact project running on Windows (also with 2019.2.17f1) runs smoothly without alteration, and without pausing the ComputeBuffers at all; we’ve previously never hit any issues with pushing a decent bit of data to the GPU via this route, so am a little surprised, but perhaps is indeed running up against bandwidth limits (AMD D500) of this machine or simply via the “timing” of the data sends, perhaps?
Some Profiler screenshots posted here: Unity 2019.2.17f1 on macOS - Major EditorLoop Slowdown - Album on Imgur
Is there anything specific that would be helpful to see or to help lead us in the right direction towards diagnosing the issue? Most of the screens above are with Editor Profiling enabled, to try to see where the time is going, though one screen shows the PlayerLoop time divide as well.
FWIW, the scene is fairly moderate and contains almost exclusively procedurally rendered geometry. There are ~1k objects [agents] being rendered via DrawMeshInstancedIndirect() and several ComputeBuffers to feed data to that system; only a couple of draw calls for that, and the amount of total geometry is moderate-to-low. None of the higher-volume geometry is shadow-casting, I believe the scene only has a single shadow caster which is a fairly simple procedural mesh (walls & roof). The scene runs great on Windows! =D
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.
Will do, on both! Thank you very much for the [super] fast response! 
