Gfx.WaitForPresent

Yeah, that is weird. Certainly seems like either a Unity or a graphics driver bug rather than anything you're doing.

I don't think it belongs in a Gfx.WaitForPresent thread though. The reason you've got big Gfx.WaitForPresent spikes is that your GPU FPS is ~130 and your CPU FPS is like a thousand, so it's spending tons of time waiting on the GPU. The real question is wtf the GPU is doing.

 

I just tried to load GPU alot with a compute shader. And what I got? Huge Gfx.WaitForPreset. The more I load GPU, the bigger the time Gfx.WaitForPreset consumes. Conclusion: Gfx.WaitForPreset represents the time CPU has to wait until GPU finishes its job for the current Update() frame.

 

So i was have a hugh issue with this and for the life of me a couldnt figure out why i was having such a hugh lag in a fairly simple scene.. Then after checking this thread i realized (im assuming ) a windows 10 update broke my current graphics driver. So after finding and installing the latest driver it seems to be working as expected..

 

Hello to everyone at the gfx.waitForPresent community, I was running into this "high gfx.waitForPresent time" situation earlier today, and would like to share some basic practice on how to troubleshoot this.

So first of all, let's prepare 2 standalone development builds: one without vsync and one with vsync.

Without Vsync (click for larger image)



With Vsync (click for larger image)



(It may appear my screenshots are flipped, but no, they are not: "WaitForTargetFPS" doesn't show when profiling a standalone build, for reasons I don't understand. But the game is absolutely sync to 60fps, I have an in-game fps monitor to double-check it.)

One would assume, with vsync set to 0, the game will run as fast as GPU allowed. But confusingly, in my case, it was running just above 60fps (less accurate than vsync, but still around 60fps, the time is largely shown as gfx.waitForPresent).

For a direct comparison, here is a graph show both no-vsync build (left) and vsync build (right), you can see the actual camera rendering cost about the same. The scene contains only very simple UI, so by all means it could render faster. (click for larger images)





In fact, it was running faster in the Editor, above 90fps. I have an in-game monitor to verify this. In a standalone build, also without vsync, the same scene can run at best around ~60 fps, but never quite as fast as 90 fps.



Then I realize what was going on: I was fillrate bound, not texel fillrate, but pixel fillrate! My MacBook Pro 2015 Intel GPU just can't push that much pixels onto screen. Changing the resolution, toggle between fullscreen and window mode, all has a huge impact on my game even though very little texture processing was happening.

I am also on deferred rendering which is even more dependent on ROPs (to process g-buffer).

So that's it, feel free to point out any mistakes in my summary

 

Oh and one more thing: this is why Unity GPU profiler is not enabled by default - it doesn't work on every platform. In my case, an "Intel Iris Graphics 6100" on MacBook Pro 2015. So I have to figure out my issue the hard way.

(click for larger image)

 

I wonder when this GPU profiler actually works.
I have an AMD R9 290 and a nVidia GTX 745, the profiler doesn't work in either of them, drivers updated obviously.

 

I have a nVidia GTX 960 and it shows stuff when using DirectX11 in Unity shown below:



However its blank for DirectX12 shown below:



What I have noticed is an issue where its not displaying all the Timeline sections shown in this video I have created:

I have not yet tried it in the beta version yet, so it may or may not already of been fixed.

Paul

 

Not sure if people are still having this issue but my specific case got a response a while back and it had to do with the GeForce Experience overlay causing these issues. If you've already disabled VSYNC probably try to turn off or uninstall GeForce Experience to see if that helps.

 

Thank you! Disabling GeForce Experience Overlay instantly fixed the issue - made a massive difference.

 

Excellent catch!

Did you submit a bug-report to Unity Technologies for this? I'm asking because if they don't have a bug-report for it, they're probably not aware of the problem and thus not going to fix it.
https://unity3d.com/unity/qa/bug-reporting

 

I don't think it's a bug in Unity.. It also does this when using EVGA Precision X software, likely for the same reason (overlay).

 

Interesting finding. My mbp 2017 has the same problem. In Editor, the gfx.waitForPresent goes significantly high when choose "maximize when play". I'm not sure which graphic card the device is using when running under editor mode, because mbp has two gpu. I originally thought when I chose high or ultra qualities, the device would automatically pick the most powerful gpu for me, but your finding doubted it.

 

Woah I'm happy to see that I'm not alone, but I'm confused about why this is still an issue after more than 4 years !

I don't know if their is a but with the Gfw.WaitForPresent, but there is for sure a bug somewhere, just test it by yourself:

Make and empty scene, and place a high poly model (for example a subdivided sphere made in blender) with any shader. Between 0 triangles and a few milions, the CPU and GPU time remains under 1 ms for both, and after a certain threshold, it just explodes !!! But the GPU time is still under one ms.

I don't get how this is possible. Either something is broken deeply in the engine either the GPU cost isn't under 1ms as it's written in the editor.

 

What is more strange to me is that I don't really think my cpu needs to wait for gpu. My gpu thread only takes 2.1s while the cpu thread takes 24s with 90% cpu taken by Gfx.waitForPresent. If just ignore the Gfx.waitForPresent time, both threads are roughly equal lengths.

 

Hi, I'm experiencing this weird 'GFX.WaitForPresent' and need some advice!
My scene is fairly simple : 64x64 terrain, boundaries, a car and a target.
I used Lightweight Rendering Pipeline for my target device(Mac Mini, Late 2014) with all the materials switched to LightWeightPipeline/Standard, and IL2CPP build for performance.
It works fine on my dev machine (iMac), but on the Mac Mini the GFX.WaitForPresent spikes high.
(Test resolution : 1280x720)



As you can see, those cat-like gradually growing spikes occur periodically, over and over again.
One thing I've figured out is that disabling the shadow prevents those spikes. My app runs over 200 FPS on Mac Mini. And the V-sync option was irrelevant.

I only used hard shadows with the Shadowmap Resolution to 1024 and reasonable shadow distance(60). And there are roughly 10 objects casting shadows.
So, I'm wondering how this can cause GFX.WaitForPresent.

------------------------
EDIT1
Mixed light(baked + realtime) caused this issue. After disabling the lightmap, the shadow option no longer causes this spike. I really want to use the lightamap, though...

------------------------
EDIT2
Sorry. Shadow Cascade option causes this spikes. Setting it to 'No Cascade' makes the app run smooth.

 

For what it's worth, the distance you render shadows makes a big difference, as does the resolution of your shadow maps. What I noticed is in my game, if you go above "medium resolution", it takes more time to generate the shadow maps, but looks about the same (after I tuned the cascades properly). The shadow distance matters a lot, too, because the farther you render them out, the more objects have to be re-rendered. Check the shadow passes in the shaders being used, too, because in a LOT of shaders, it's doing full complex calculations for what will ultimately be a black pixel. They have to do that only to support punch-alpha shadows, so in some cases you can make that a lot faster just by changing the shadow pass.

For people who are confused by the fact that the GPU says it's only busy for 1ms but there's a long GFX.WaitForPresent, it's usually because it's only measuring how long it takes to send the instructions to the GPU. If you have a lot for it to render, it will take a long time before the GPU is available again, and you get GFX.WaitForPresent in the meantime. Simplify your shaders, reduce draw distance, find places where your CPU and GPU are waiting on each other, etc. The usual. Sometimes it's an asset pack on the store that's badly behaved, or a badly written shader or plugin. Try toggling things off at runtime until it magically goes faster. If you resize your window larger and your frame rate drops, it's a sure sign you have a fillrate / shader / GPU bottleneck.

 

Just been hit by this issue and it seems pretty random. A simple scene with 500 particles and a couple of background textures renders at 150fps when not maximised with 5ms GFX.WaitForPresent. Maximised, however, I hit 15-25 fps with profile bumps, from 0 to 90 ms and back down to zero on maybe a 1/2 second interval. I've turned off and on some aspects like background and UI, to end up with the same scene and yet a different profile; now I get spikes of 120ms rather than bumps.



Reducing the number of particles reduces the WaitForPresent.

 

As weird as it sounds uninstalling the Nvidia overlay and rebooting massively increased my framerate.... 60 odd to 800+ FPS

Now getting more what I'd expect from a 1060 GPU.

 

If you are on MacOS, try disabling Metal.

Project settings > Player > Other settings > Rendering > Auto Graphics API For Mac (uncheck)

Then drag OpenGLCore above Metal in the list.

My Mac mini was chugging on simple scenes, with Gfx.WaitForPresent in the profiler. After switching to OpenGL my fps is in the hundreds.

 

Interesting, I'll give a try. But it is confusing as metal should better be supported than opengl.

 

It was worth a try, but that massively downgrades the performance for my project.

There's a known bug in Unity's Metal support that appears to be related to the Gfx.WaitForPresent issue, but unfortunately it's not going to be fixed in 2017.4 as the patch impacts too many other components (it's tightly-coupled). In my case, this means I'm forced to update to 2018.3 if I want to port the game to macOS.

 

What's the word on this? Is it me or Unity? What should I be looking for?

 

When I uncheck Tree & Detail Objects > Draw in Terrain settings, Gfx.WaitForPresent calms down to 0%, otherwise it's 50-54%.

 

I was having the same issue, showing up as both:

Gfx.WaitForPresent
+
PostLateUpdate.PlayerUpdateCanvases > UIEvents.WillRenderCanvases > UGUI.Rendering.UpdateBatches > Canvas.BuildBatch > Semaphore.WaitForSignal

But primarily the latter. I didn't anything when Googling for UI Sempahore spike, so hopefully future searchers find this.

It was fixed by updating Nvidia drivers.

 

I still get this issue with certain scenes, and I can't figure out what triggers it. I used to assume it was set off by a large number of GOs (polys didn't seem to make a difference) but some scenes with huge #s of GOs have no problem whereas others with a smaller number run very slowly and the profiler shows the dreaded Gfx.WaitForPresent taking up 70%. Maybe expensive shaders are the cause? Most people here seem to think it's partly or often caused by the GPU lagging.

 

I too just started experiencing this GFX.WaitForPresent issue in the profiler and I think I have an interesting test case that can eliminate many of the root causes passed around here.

So, I'm working on my game and I simply made another copy of the project (it's my terrible form of source control).

So, working on this newly made exact copy of the original project, I made some very modest refactoring changes and decided to profile the copied project (which is, for all intent and purpose the same project).

Was shocked to see that in the newly copied project with only minor refactoring I reliably had the GFX.WaitForPresent issue while the original project didn't. I could compare this in real time by opening both projects at the same time and going back and forth playing one and then the other!

The builds are the same (5.4.2f2).

So I can say for sure that it's not enough to say that this issue is caused by OS changes, graphics cards or any other system/scripting state changes. It is essentially a random bug.

Now, after going nuts looking up a solution for a while I had the idea to simply close my project that had the issue and check again.

PROBLEM GONE!

It is a problem, however, and it can probably come back as easily as it went away. And if it effects builds then it's a real issue though this hasn't been the case for me.

 

::beats head against the wall:: Does anyone know whether it affects builds?
This is the sort of thing that the "Game Dev Must Be Fun" guys do not understand at all, along with a host of other things they don't understand.

 

Well, I should say that even while having the problem I ran a build and the FPS seemed as stable as I would want it to be. So I concluded that it didn't affect build state. But of course I didn't have access to the profiler so it's possible something was spiking at single frame every n frames and it was just too much of a blip to notice.

I too thought the issue had something to do with the amount of GameObjects as I had hundreds going at once.

What made me suspicious that this was a random glitch was when I decided to just go to an empty scene with nothing substantial running in it (just the camera).

And it had the issue as much as the scene littered with GO's.

That's when I closed everything down and restarted back up and it was gone in that project.

My advice is to run builds when you see the issue and you should be able to tell if it's an issue in the build state. If not, I wouldn't sweat it too much.

 

Out of nowhere I get this too now. It's spiking so much it's making doing anything in Unity 2019.2.17f1 unplayable on my laptop. A week ago this was fine. I usually only have Unity and VS Code open, with the browser only being opened for stuff like this.

Also this thread is rather old now, shouldn't there be some measures in place to warn the user that something is not right?

[edit] It seems to be coming and going, without me having done anything. Sometimes it's fine with the web browser up and not when I don't have it open. It doesn't make sense. The only thing I can think of that has changed is that I did a Windows 10 update recently, but that should not impact this, I hope.

 

There has been ongoing confusion about GFX.WaitForPresent over the years.
"WaitForPresent" is just letting you know how much time your CPU has needed to wait for your GPU before continuing into the next frame. I've seen a lot of blame placed on our old buddy WaitForPresent as though he is a resource Hog, or some ruthless malicious Bug. But let's not "shoot the messenger". He's just doin his job!

Here are some of my favorite ways WaitForPresent may get triggered:
You're profiling on a Laptop running on battery power and your GPU is getting Throttled. (Plug it in!)
Your GPU may be working on other stuff outside of Unity
Your VSync may be on
Your Graphics Driver might need an update, so your GPU is now chugging on stuff it wasn't before
NVidia might be running In-Game-Overlay (Turn it off in "GeForce Experience")
You might have a second monitor plugged in

Adding to the confusion might be the number of requests you might see from Unity Tech asking for "Bug Reports". This might be very helpful for solving unusual GPU spikes that shouldn't be happening, but "WaitForPresent" is never the cause. He is just the messenger. He is just misunderstood. Hell, he probably just needs a hug..

 

I did the deep profiling and it did not show up. However now it's become inconsistent. As stated in my previous post, the only thing that has changed was a Windows 10 update.

 

It's a good idea to check for a Graphics Driver update whenever you have a "Windows" update.
When you are profiling, also make sure you have no other apps running that could be using your GPU (including browsers)

 

I quote myself:

So it might be a driver, then.

 

Unity 2018.4.19f1 (LTS)
Using lightweight render pipeline
In my scene I have a simple canvas with a button in it using TextMeshPro
My laptop specs are:
16GB Ram
GTX 1060
intel core i7 7th gen
Game runs at 1000fps (Without the editor loop)
Build is for mobile
Build the game and run it on my phone (Samsung A5 2016)
Game runs at 15fps
Check profiler, the issue seems to be GFX.WaitForPresent taking between 40ms-70ms

So Yes, Gfx.WaitForPresent Affects the build.

I also tried closing and opening project, turning pc off and on and rebuilding, nothing helped so far

 

I had the same issue a week ago and the problem was that my PC's first screen was duplicated to my TV.
I saw in the second comment of this thread that his PC was connected to his TV.

 

I wish if someone from the unity dev team would give us some advice on what we should try

 

okay, I added "You might have a second monitor plugged in" .. to the list:
Things to Try

 

@Martian-Games explained it well a few posts above.

GFX.WaitForPresent just tells you that GPU is taking more time than CPU and it has to wait for it.
To get insights on why is it taking so long, please enable GPU Usage in the profiler (it's not enabled by default as it doesn't work with some GPUs and drivers).

 

Here's a good explanation

 

So I had this error lately and in my case, it was Nvidia control panel

Here is the video of how I did a few things mentioned in this thread
Feel free to skip with timeline for Nvidia fix

 

For some reason, my editor is extremely laggy when I start dragging or zooming in edit mode. The profiler also showed that GFX.WaitForPresentOnGFXThread took a long time (~120ms). I couldn't run the GPU profiler because Unity doesn't support it in edit mode. I'm currently using Unity 2020.3.37 (This also happened on older versions) on Windows 10 64bit. What should I do now?

 

Run. Run far far away. Nothing can help you now.





(Sadly, I'm only partly kidding.)

You could start by posting your system specs, graphics card model / driver, and exact windows 10 build / version number.

 

I7-8700
16 GB DDR4 ram
GTX 1070TI (driver version is 30.0.14.9676, Geforce Game Ready Driver version is 496.76)
Mainboard B360
Windows 10 64-bit, version: 21H2, OS build: 19044.1826

 

By any chance, are you using a gaming mouse with a high polling rate?

If so, try turning down its polling rate to something as close to the frame rate as possible. Or plugging in an old mouse, instead, that has no enhanced/highrate polling.

 

My mouse has a polling rate of 1000Hz. I changed it down to 500Hz, and the problem still exists.

 

If the polling issue is the problem causing your slowdowns, you'll need to read what I wrote a little more closely - get that polling rate at or close to your frame rate. 500Hz is still 8x faster than the default frame rate of most monitors.

Can you get it down near 100Hz?

Can you find a very old mouse and try that instead?

Unplug the mouse altogether, and try that?

 

I don't know if the polling issue is causing the problem. I can only change it back to 500Hz and don't have any older mice.