This doesn’t happen in all scenes, and sometimes deleting most of the objects out of a scene fixes the issue. I have not been able to figure out what is in fact causing the issue, because the objects that are deleted which solve the issue are never consistent (deleting half the scene may fix the issues once, but trying again to delete the same objects doesn’t solve the issue if the scene is reverted).
Sometimes I enter a specific level and get 250 FPS, and sometimes I enter that level and get 2 FPS. Interestingly, I was getting fairly consistently 2 FPS several times in a row… until I noticed that Microsoft Anti-malware was using a significant amount of CPU. As soon as I disabled Real-time protection, Cloud-delivered protection, and Automatic sample submission from the Windows Security center, I turned on the build and got full performance again. It also kept that full performance when I turned those settings back on again, though.
Could be a co-incidence.
It’s especially weird that it pretty much affects a single scene, and that scene isn’t very complicated. (I mean, it gets 250+ FPS on a good day.)
I’ll file a bug report.
(edit: I should note that I do not have the March 1st Windows Update installed, which is known to cause performance issues of some sort. My most recent update is the February Patch Tuesday security update. This bug is not related to the buggy, March 1st Windows 10 update.)
He said he can’t figure out what is causing the issue, not that he’s unable to reproduce it. If he sends us (a part of) the project that demonstrates the issue, we can have a look at it.
Sorry I have rolled everything back, because this project has a pretty tight deadline, but I will investigate a minimal repro when I have available time.
So it turns out that Windows Security may not be the issue?
I just had two instances of Unity open, one in 2019.1.0b7 on my main project and one in 2019.1.0b6 on the buggy project that I submitted with 1136028. (I was intending to copy some shadow settings over from the test scene.)
I noticed that the 2019.1.0b6 (buggy) project had massive editor lag. The 2019.1.0b7 project was responding normally during this time. I took a screenshot of the “Profile Editor” on 2019.1.0b6.
I turned off Windows Security (Real-time protection, Cloud-delivered protection, and Automatic sample submission) and the lag persisted. I restarted the Unity instance that was laggy, and the lag persisted when it relaunched.
I started typing up this post without turning off either Unity instance any more times; after a handful of minutes of writing this post, I noticed that the editor “fixed itself” and it was responding normally.
Unless Windows Security refused to give up several minutes after I shut it off, it looks like it may not be the cause. The “wake up” when I shut it down last time was just a coincidence.
I have not attempted to use the buggy project in 2019.1.0b7 yet. I’ll let you know if I see the problem (either in the buggy test-project or in the main project) in 2019.1.0b7 (or later).
Edit: Just a few minutes after posting this… the main project (in 2019.1.0b7) started to lag. It happened as I was editing shadow settings for the scene’s Directional Light although that likely has nothing to do with the actual problem.
Is there any news on this? We’re still facing a significant performance hit (apparently) due to Semaphore.WaitForSignal() calls in 2019.1.0f2. This seems to have been introduced in an 2019.1 alpha or beta release, as I don’t recall encountering this issue on 2018.3.
Semaphore.WaitForSignal is a sample which wraps semaphore waits. In this case Gfx.WaitForPresent underneath is waiting for semaphore signal from Render Thread. In 2019.2 we only exposed this internal behavior to profiler.
I would look at what Render Thread is doing during these abnormal frames. Perhaps GPU profiler can explain high present times.
Hello there. I’m facing a similar issue unfortunately I can’t get any info from GPU profiler as it’s all listed as “other” https://discussions.unity.com/t/740687
For me, If I use a certain material within the ui i get the semaphore.waitforsignal in the profiler using 47.1ms and my fps drops from 800 to 40 fps. Using 2019.1.0f2 and the hd srp.
Strangely, when I do a deep profile semaphore disappears and the ms goes from 47 to 6.
Here is a screen shot of it taking place now. Its no longer a UI issue as I have all UI elements disabled. Very strange stuff. Im using the HD SRP UnLit shader with gpu instancing enabled. In my RenderPipeLine asset SRP batching is enabled and in player settings I have experimental graphics enabled. The highlighted section in the profiler is the semaphore.waitforsignal, as you can also see by looking at the stats my cpu main is well over 100ms. I have 32 gb of ram and a 1080gtx graphics card. If you would like I can export this scene to a unity package to see if you get the same results.
Please submit a bug-report as described in this document:
It’s important that you report these issues together with a reproduction project if you want them to get fixed. If you don’t do it, it might be a long time until someone else reports them or until Unity Technologies find them.
After you submitted the bug-report, you receive a confirmation email with a bug-report Case number. Please post the Case number (number only, not the link) in this forum thread for Unity staff to pick up.
We have a few world-space canvases with animator components attached and set to always animate, that seemed to be the cause of this.
In 2018.3, there is no issue with multiple canvases with simple animators, in 2019.1.0f2 it has massive spikes in semaphore.waitForSignal, and everything in GPU profiler is listed as ‘other’ also.
