- Home /
GFX.WaitForPresent
In the profiler I keep getting information on something called GFX.WaitForPresent. Its eating up 66% and its so annoying! Can anyone explain to me what this is, and what I can do to stop it?
That sounds like a VSync thing. If I'm right, it's not a sign of slow performance, it's because the rendering system is waiting for a few miliseconds to match your monitor's refresh rate. If it takes up 66% of the resources, it's actually because the REAL work your computer has to do only takes 33% of the time available between two monitor refreshes.
Could you elaborate a bit, and perhaps tell me a solution?
I got the same issue. This is definitly a bug! I noticed when you rebuild your terrain using the same settings it seems to be gone for a while but it's co$$anonymous$$g back after working again in your project. $$anonymous$$y temporary solution is rebuilding my terrain plus shaders when it happens (I'm using TerrainComposer+RTP so it isnt a big deal).
GFX.WaitForPresent is not a bug, and if I'm right that it's vsync kicking in, it is not a performance issue, and you do not need a solution. This is an idle task meant to match your frame rate to that of the monitor to prevent screen $$anonymous$$ring, please look up "screen $$anonymous$$ring" on Wiki.
Answer by Ed unity · Mar 12, 2014 at 03:02 PM
This is absolutely not a bug. As CHPedersen is trying to explain to you, this is Vsync. If you do not know what Vsync is please look it up. In short Vsync is the vertical sync to switch the Render Target with the back buffer. This way you do not get screen Tearing as CHPedersen had said previously. This is not in fact a CPU bottleneck. This is merely to keep your game at 60fps even though it can go higher. If you go to Edit->Project Settings->Quality, in the Inspector window you will see VSync Count. You can switch between No Vsync, Vsync, and Every other Vsync.
Ed unity is absolutely WRONG. IT IS a bug this thread shows enough amount of people with it, sadly Ed unity didn't checked his facts before posting, and answer status should be revoked.
I agree. I do not use vsync in my project and have it turned off right now while whatever gfx.waitforpresent is eating up 80% of my cpu resources. This bug magically appeared from nowhere when I started up my project today and I have changed every setting re installed unity and turned off everything in my scene to no avail. Certainly sounds like a bug to me.
It clearly isn't a bug and you should simply learn the basics of how the graphics hardware works ;) Nowadays there could be multiple places where you can turn vSync on or off. $$anonymous$$ost graphics-card drivers / configuration programs (like NVIDIA) provide a way to globally enforce vsync or to set certain settings on a per-application-basis. I've also seen graphics drivers which don't provide an option to disable vsync.
Also keep in $$anonymous$$d that there is also Application.targetFrameRate which also artificially lowers the framerate and in webbuilds it defaults to 50 / 60 fps
"this thread shows enough amount of people with it" Do you have any idea how many people are using Unity? If it's a regular bug there should be at least a few thousands of people with this problem and it should be reproducable and filed as bugreport.
Feel free to search the known bugs and if you think you found a new one, file a bug report ins$$anonymous$$d of writing a rant on a community driven Q&A site
This is not a bug, it's the graphical rendering equivalent of "System Idle Process" in task manager
Answer by Stankiem · Feb 19, 2015 at 09:09 AM
It's much simpler then any of these other answers. You're looking in CPU stats. It's simply saying the CPU is waiting for the GPU. Look at your GPU stats and you'll see exactly what's taking so much time. =)
This was the one for my scene, GPU hitting the wall with 100% load.
This is actually the real answer. Forget what everyone else said.
I was checking the wrong thing the whole time. Turned on my GPU in the profiler like Stankiem suggested and BA$$anonymous$$! Saw all the spikes and reasons for the GFX.Waitforpresent "bugs" in the CPU section.
Post processing Image Effects and shadows were the culprit.
Thanks man!
This Unity tutorial confirms this: "If the function Gfx.WaitForPresent is taking the longest in the CPU Usage profiler, this indicates that the CPU is waiting for the GPU". See the section on "Rendering profiling" specifically. The article is a bit old but still has great in-depth information on profiling :)
Answer by WhendricSo · Mar 13, 2014 at 02:33 PM
This resource actually has to do with rendering the shadow buffer. By turning off real-time shadows, you can eliminate it. Be sure to use lightmaps whenever possible (Window -> Lightmapping).
Unity has the Beast Lightmapper built-in, it's very powerful and produces excellent lighting results. If you are using light-mapped-only lights, you can add light probes (pro only) to get nice lighting on real-time objects. Or, if you are using indie, baking lights with shadows then turning the shadows off will give a nice mix, as long as the lightmapping mode is set to "Auto". By setting a light to "not important" it will be rendered as a vertex light which is good if you need many real-time lights in your scene for this purpose. Always try to reduce the number of real-time lights wherever possible, this will improve performance greatly.
If you can't use lightmaps, for example, in a procedurally-generated world, limiting the number of shadow casters on screen is the way to go. Also, using as few lights set to "important" is an excellent step, and some lights can be set to "not important" which will enforce vertex-only lighting for that light. This is good for lights that cover a large area in polygon-dense places, but not smaller lights. Vertex lighting is unrealistic but very fast and even vertex lights are a good addition when used correctly.
If you are on this answers page, it is likely you already know that good lighting improves scene quality greatly, and using all the tools available to achieve it is key to successfully implementing an eye-popping scene while keeping framerate consumption to a minimum.
Thank you to impossible for this tip. After checking all lights in scene and making sure they had no shadows, my program freezing up went away. The shadow buffer for real time shadows must have filled up after playing a $$anonymous$$ute or so, then suddenly made my profiler GPU solid purple for another $$anonymous$$ute (making it less than 15 frames per second) before suddenly going smooth again - back to 30 frames per second.
Answer by SeveneduS · Jan 01, 2015 at 12:41 AM
Problem exists even in blank 3D/2D projects with absolutely minimum quality settings.
This is not actually a "problem". In that same blank scene, make the cpu do some work and youll see the % "waitforpresent" drop. It simply means the gpu is doing more work than the cpu, so the cpu is waiting for the gpu. Rendering the camera in the blank scene will be what the gpu is doing. Cpu is doing nothing except waiting.
Answer by Voronoi · Dec 29, 2015 at 09:56 PM
I found this also showed up when setting the Player Settings to Multi-Threaded rendering on an Android device. I believe the device could not do this, so it was waiting for another thread all the time, which it didn't find.