Gfx.WaitForPresent

Maybe sebas77 wasn't actually correct and that's why most people ignored it. It does seem to be the case for me though that WaitForPresent only appears when my game is GPU bound, to make up the time difference.

Could you post a screenshot of your profiler with both CPU and GPU usage visible?

 

I'm also new to the profiler so I could be missing something, but I've only had this issue in Unity 5. I'm on Windows 8.1.

 

Sorry, I meant the actual GPU profiler, like this:


You can click on Add Profiler at the top left to add GPU.

 

It's frustrating because there's really not much I can do with Unity at this point, the stuttering is so bad. This particular scene is a little more than a few cubes but I have the same problem in a pretty much empty scene.

 

Gfx.Wait is very strange.. Dealing with 2 monitors .

I take my game screen, drag it in the second monitor. Then i deal
with the Aspect ratio, with custom screen..

In the first monitor unity editor is in animator so the scene is not visible



After a while my fps become normal and gfx.wait go away.
300fps and CPU 2.0 ms is again 4000fps and CPU 0.3ms..

This solve it for me for the moment.. Was searching in my shader
code for nothing...

 

It's really strange.
This and a few other huge issues are causing me to go back to 4.6 for my project.

 

Very strange.. I've fixed it for now for a simple stress test with particles but maybe i will see it again with all my complex scene..

When it appear you begin debugging anything in your scene.. It occur with some shader at 1000 particle when the particles are larger and take fullscreen ... But this is not the shader , not the number of particles... When the render become more complex in some random way Gfx.Wait occur and take almost everything ... But with my screen tricks i prove this is not the shader and not the particles ...
(Note that also close Inspector, hierarchy, Project windows could help with it (not sure) )

 

Gfx.WaitForPresent just indicates that the CPU's work is taking less time than the GPU and so has to wait for it to finish. In your screenshot you can see that your WaitForPresent on the CPU is running just long enough for the CPU framerate to match the GPU. You are GPU bound. If you reduce the amount of GPU work, you should see your CPU work decrease as well. But again, WaitForPresent isn't work that you should worry about in itself - it just indicates that the CPU is waiting for the GPU.

Not to say you don't have a real issue: If you can only get 30fps or less in an empty scene that is of course a problem, but it's a GPU problem rather than a CPU or WaitForPresent problem and probably belongs in a different thread. Your CPU is doing hardly any work at all, which is why it has to wait so much of the time for the GPU. You'd be free to fill all that WaitForPresent time with actual CPU work and you wouldn't get any worse framerate.

TL;DR:
Some people are having a real problem with graphics performance, but CPU and WaitForPresent has nothing to do with it - it just means the CPU is waiting for the graphics. Trying to 'fix' WaitForPresent is like trying to fix a thermometer to reduce the heat.

 

The issue is the framerate stuttering. I'm getting framerate jitters for no apparent reason and it seems to correspond with Gfx.WaitForPresent.

 

This is really not what i see !!!
Why the CPU will wait 2 ms when my render Threat take 0.1ms ?
Maybe Gfx.wait is more The GPU waiting for the CPU
but for me it's a bug when the editor windows is still active when in game mode..

 

Can you see how WaitForPresent is just filling up exactly the remaining time the GPU is taking though?


WaitForPresent will get "worse" when GPU performance gets worse but it's not the problem in itself.

That does sound weird. Could you post your CPU and GPU in the profiler like randomperson42 did so we can see? Make sure you have VSync off in the Quality settings, just in case that could be it.

 

Sound crazy but my GPU is at 0ms.


Now i switch the editor Scene view to the animator view :

 

It does look like it, but could you show one with the GPU profiler showing (like in Randomperson24's most recent screenshot)? You can add it via Add Profiler at the top left.

This definitely can be an issue too, because the scene camera acts like another game camera. It even affects isVisible.

 

Thanks ! Now i know where's my GPU !) Sorry for my noobisme

When i add the GPU to the profiler Gfx.wait disappear, i could see it's the GPU
that take 11ms. (this is not the same scene.. I erase it) Strange also when the profiler is open the fps is better..
You are right ! It's waiting for the GPU ..
For me it's the Editor Scene that are rendering twice. But thanks to you i understand that the stats windows don't take GPU in account.. In reality
i have 500 fps and not 5000..

 

Cool. You can also click on GPU Usage to see the full breakdown in the overview. Running with Deep Profile on will give you even more data. Although GPU usage stats can still be pretty vague sometimes.

And yeah, don't have the Scene view open when profiling the game because it definitely does its own stuff as well.

 

It help me a lot to profile my shaders !!!)

Gfx.wait almost disappear, but it continue to causing spike..

I see in my Gpu that the color correspond to other.
In the Overview all the process keep the same ms value
for this frame. The other is not visible..

So i supose that in this case those spike come from something else in my computer and not unity ? Do you think i'm right ?

 

Your Mesh Memory (under Memory) spiked at that point as well, so it could be something that happened within Unity.

 

I notice that. But i don't think it's the true cause, the spike occurs even when there's nothing with the mesh..

I make a script that count how many time Time.deltaTime is > that x ms.
Without the profiler i have regular spike at 10ms whit an empty scene.
if i touch a windows like inspector, hierarchy, the spike happens more fast,
almost at all frames.
When i use the profiler the spikes go up to 15ms..

Will do more test to see if it happens in build, with other computers...

 

The same for me. Unity 5, win 7, 2D graphics. Latest video driver installed.


As you can see, my GPU spent much for Mesh.SubmitVBO and Clear. My graphics is pretty simple, will see if there are any non optimised issues

UPD: Problem solved for me. It was a texture setting. I used 32x32 2D sprite with a setting of Max Size 2048. And this sprite was used as background. I switched Max size to 32 and FPS increased significally.

 

I had this issue because I had 2 directional lights, both with shadows enabled. When I removed one of them or when I disabled the shadows it was fixed. Maybe this could help some people.

 

Once again, that is because Gfx.WaitForPresent just means that the CPU is doing less work than the GPU and having to wait for it, and therefore creating less graphics work for the GPU will always help. Gfx.WaitForPresent is not a thing that's taking up time in itself.

The answer to "how do I fix Gfx.WaitForPresent" is actually asking a different question: "How do I improve my GPU performance?"

 

If you are working with Oculus and have this issue,
Add this line of code:
OVRManager.capiHmd.SetEnabledCaps((uint)Ovr.HmdCaps.NoVSync);
This fixed it for me. I spent 3 days going crazy about it. Now I feel like helping you guys out. Hope it helps! Cheers!

 

Once again, Gfx.WaitForPresent is not a thing that's taking up time in itself.

Because you had VSync on, your frame rate was automatically limited, and therefore the CPU had space to wait for the end of each frame. By turning VSync off, you let things go as fast as they can, so the Gfx.WaitForPresent disappeared (note: If your GPU was still taking up more time per frame than the CPU, it wouldn't have disappeared entirely).

Gfx.WaitForPresent cannot be "fixed" exactly because it isn't a thing, it just represents a wait.

 

I was having spikes with 90% in Gfx.WaitForPresent. Then I fixed it by closing my Chrome browser...

 

To kind of solidify the "Gfx.WaitForPresent" is really doing nothing crowd, DirectX has a Present function that "Presents the contents of the next buffer in the sequence of back buffers owned by the device." WaitForPresent is just waiting for that function to be called before continuing on to processing the next buffer. The profiler would log the time the cpu was waiting. The cpu is actually doing nothing but checking whether that function has been called. Switching the graphics over to OpenGL may seem like it fixes it, but that wouldn't solve whatever problem is causing the delay, just not report a WaitForPresent call.

 

I wanted to add my voice here and say that I have seen this same issue with high Gfx.WaitforPresent in the profiler since updating to Unity 5. I've tried the various solutions offered here (vsync off, etc.) to no avail. Empty scenes, demo scenes, you name it, they all have this issue.

 

Sometimes it's the editor and his windows. The stats windows overlapping with the game view could provoke it.
Sometimes i have to change the resolution of the game view multiple time then it disappear.
The inspector, Project and hierarchy windows could also mess with it. Specially if the inspector show a script
with lot of variable changing. I also change my windows Text from Large to medium and maybe it help..
This image show how i fight with it when profiling:

 

Could you post an image of the cpu profiler with the GPU profiler also enabled in an empty scene to show us that its actually an issue during empty scenes, images like the ones nition requested? Demo scenes makes sense as they are mostly gpu renderering with little CPU overhead.

 

If an empty scene is mostly GPU work and hardly any CPU, of course it will have a major WaitForPresent component on the CPU though. That sounds normal. GPU is doing more work than CPU so CPU is having to wait.

If chiapet1021 told the CPU to count to a billion every frame or whatever, the WaitForPresent "issue" would magically be fixed.

 

Thanks so much for clearing up what that was! All makes sense to me now. Was trying to get to the bottom of Gfx.WaitForPresent for weeks and your posts explain it perfectly. I think the point of confusion was that GPU seems to be hidden by default in the profiler, so the rendering processes at first glance (CPU) seem to be taking far less time than they actually are.

 

Yeah, having GPU showing by default would probably reduce the posts in this thread by at least half. Glad I could help.

 

Is there a way to make CPU do some of the GPU's work?

 

What about occlusion culling?

Also I have LOD groups to almost all of my scene's GameObjects, but I only have one LOD and then just culling. Would it be better to add a few more LODs?

 

57715, member: 432262"]Resources[/QUOTE]


Unity 5 closed after vertical sync Gfx. WaitForPresent remains high

 

I have issues with Gfx.WaitForPresent as well. I did some tests and I came to the conclusion.
First some Info:
Shadows disabled, deferred rendering, linear color, VSync doesn't make a difference. The scene is RTS like. No occlusion culling, no light maps, in general no static objects. No LODs.

I only get a high value on Gfx.WaitForPresent (up to 20ms) when I have many lights in the scene and only when I zoom into the scene. The strange thing here is that when I zoom into the scene actually there should be less to render and the Rendering section in the Profiler proves that. Also the objects (shaders, mesh, materials) should be the same.

Maybe it has to do with an individual issue with the game, but does someone have a clue?

 

I want to add a conclusion to my issue above. I believe it has simply to do with how deferred rendering works. Each light is rendered as a mesh (Point = Sphere) and (Spotlight = Cone). When there are many lights which take a big area of the screen it seems that it is too much for the GPU to render all the lights. It has limited possibilities to cull the lights and therefore has to perform a lot of (nearly) full screen passes. This could be considered as an overdraw.

Can someone confirm or correct that?
But if so, then I would say if someone encounters GFX.WaitForPresent, then you have to try to optimize your game first before blaming Unity It simply says that rendering has to do to much work. That's at least for my case.

 

what is "LOT"

 

Some graphics card force vsync. Some allow you to set the vsync setting like nvidia does with its control panel.

 

-force-opengl works for me. Windows 8.1, latest Unity 5.1 Pro release. Curious as to why this cropped up in the first place. Does this mean I can't run using DirectX?

 

FWIW I get this problem with the stats window open. When closed the issue goes away.

 

This problem have been a massive headache for me for several days, and it got solved for me by running Unity in compability mode with Windows XP SP 2... (Unity 4.5.0, win 8.1, OpenGL ES 3.0, building for Android)
So in my moment of relief, I just want to thank all of you who have shared your solutions!

 

I get this problem when running the app on an Android device, and profiling it from a Windows 8.1 PC.
A question I don't understand: does it affect Android normal gameplay, or is it just a problem related to the Windows editor?
Thank you

 

Gfx.WaitForPresent means that your cpu is waiting for gpu to finish a frame, thats why it shows high ms, it basically waits doing nothing for that ms. Basically the more waitforpresent you have, the heavier is the struggle for gpu to catch up the cpu.

 

If the 195 replies above don't help, a few more tips:
1. If you are working on a laptop, and you aren't working in a freezer, you might be a victim of temperature throttling. ( Laptops try to keep themselves from melting by slowing down your GPU when they heat up.) This will show up as Gfx.WaitForPresent in the profiler.
2. Your laptop might also annoyingly slow down your GPU, to save battery life, if it is not plugged into the wall. (Plug it in.)
3. Your GPU might be simultaneously running other applications. (Close all browsers, and 3D programs which might be concurrently hogging your GPU.)
4. And of course, (already mentioned above), if you need faster than 60fps: Turn Off V-Sync

 

If anyone is having issues that aren't resolved. I had bad editor jitter that was showing up as gfx.waitforpresent. I found this post HERE solved the issues.

Basically EVGA precision x 16 has two unnecessary application files that run in the background and destroy unity editor performance.

 

Does anyone know why the CPU might wait 61 ms for the GPU when the GPU Usage profiler reports drawing each frame in about 10 ms? It's hard to believe the CPU needs to wait for so many frames and there's no indication of why the GPU might have a long frame. Waits of sub 16 ms might be expected from vsync, but not 60 ms.


Here's the CPU info for that line as well. This is a test scene with nearly no scripting running. the camera is slowly panning over a static scene.



Any insights would be greatly appreciated!

 

hi Andy, welcome to the Gfx.WaitForPresent community!
Please read my reply #196

 

Hi Martian Games! I am glad to be here and happy to add to the discussion I did happen to read that post.

I think I can confidently rule out 1 and 2.

3) Are other applications using the GPU? The frame rate has the same choppy behavior when all the apps have been quit and I'm running the standalone desktop build. The screenshots above were created while Unity was running and was attached to the standalone build. I did hide the game and scene view in Unity, since those are rendered on the GPU and that might have some effect. So I definitely took steps to mitigate this issue.

4) Vsync- at 60 fps you can expect the CPU to have to wait up to 16.6 ms to sync with a refresh. So if I had a bunch of 15 ms waits I'd be able to write this off as no problem - working as intended. However, I'm getting 60 ms waits. I would love some other way to measure what's going on in the GPU for that period of time.

Thanks for your polite response on what is obviously a contentious issue, hehe