Extremely slow editor in 2019.2.0a7

Since updating to 2019.2.0a7, many of our scenes have become unusably slow in the editor (1-5 fps)

The culprit seems to be Semaphore.WaitForSignal in the editor windows



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).

We are also using HDRP 5.6.1.

Any help tracking this down would be great.
Chris

 

I seem to have been getting a similar issue... even in builds, not just the editor although I've seen it in-editor, too... on both 2018.3 and 2019.1.


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.)

 

yes I get this , it happens in builds as well, non SRP

 

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.

Thanks

 

I opened an issue with the ID: 1136028

 

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.

Possibly introduced on 2019.1.0a12? https://unity3d.com/unity/alpha/2019.1.0a12

• Profiler: Added "Semaphore.WaitForSignal" profiler marker.
  

Not sure if we just became aware of this because of the profiler marker, or if it is actually causing the slowdown, but might be worth confirming it.

 

Hi,

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://forum.unity.com/threads/performances-issues-oculus-unity-2019-1-0f2.666664/

 

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.

 

Knock on wood, I haven't seen the issue for about three weeks now. So weird.

 

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.

 

Happening with me, too.

Using 2019.2.0a13

 

Sooo, this mostly seems to happen when maximizing the game tab. Also, hdrp seems to result in cpu usages between about 7-10 MS in empty scenes.


23:17 edit:

The framerate issues are a problem in standalone builds, too.

 

Still no solution found, but: This issue didn't happen with 2018.3 versions back then, checked some old profiler screenshots.

 

Please submit a bug-report as described in this document:
https://unity3d.com/unity/qa/bug-reporting

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 the same issue.

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.

 

Please submit a bug-report as described in this document:
https://unity3d.com/unity/qa/bug-reporting

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.

 

Our project can't be tested without Unity first installing our application to have all the prelim data setup, so we can't submit an effective bug report just via the Bug Report system.

However, I might make a new unity project where I can force the reproduction of these spikes without needing to send our software across.

 

I believe that would be the recommended way to get a reproduce for Unity Technologies too. The easier it's for them to reproduce an issue, the more likely it's to get fixed.

 

I started seeing the OP's issue on macOS Mojave (10.14.4) after upgrading from 2018.x to 2019.1. Perhaps related, I also started using Unity Hub to manage Installs rather than direct installations.

Ultimately the issue was alleviated by turning on vsync (using the button in the Game window's menu bar). I don't see the issue on my Windows 10 machine with vsync disabled.

Before I figured out the vsync solution, I was able to mitigate the issue by turning off Metal (using OpenGL instead) in the Player settings menu. Perhaps there is an issue with the way Unity's Editor handles Metal without vsync.

I did not see this issue when using 2018.3 from a direct installation, though I can't say for sure if I was using the same revision of Mojave at the time.

 

https://forum.unity.com/threads/samples.522629/page-3

Some tests on the newest post here

 

With gpu profiling turned on, the render thread usage and gpu usage is suddenly really high, which seems to be the correct data, compared to before. Weird.


Edit:
There seems to a lot really wrong. These gpu rates weren't that high with same scene setups and tests before 2019.1, the drae call rates are sometimes off, the render usage rate isn't right until using the gpu profiler, and Semaphore.waitforsignal causes higher cpu usage because the gpu usage is high, with a nearly linear increase... soo, always higher cpu usage, it serms like.


Edit 2:
It's all running with way less problems and much faster in 2018.3 (14f1) (Edit: 2018.4 was problematic, too)

Edit 3:

Also, 2018.3 is not causing the TAA artifacts / frame smoothing, the editor is much faster (also, occlusion baking is faster and there are not the GI baking problems I had with 2019.1+ (Where baking took really long and sometimes GI wouldn't be displayed).


Edit 4: By the way, the problems with 2019.1 + were present in builds too, not just the semaphore.waitforsignal thing.


Edit 5: Okay, Gfx.WaitForPresent is still there in 2018.3(14f1), causing high cpu usage, but still, everything's running much faster and there are less editor problems.

Edit 6: I closed the profiler (GPU profiling was enabled, too) entirely, the fps rate is much higher in 2018.3(14.f1) now. And the render thread usage dropped from around 20ms to 5ms again. Similar to the time when I enabled gpu profiling in a newer unity version which showed that gpu usage wasn't at around 7ms, but 50-60ms (Also in the stats tab in game view)

Edit 7: Also, when having gpu profiling enabled, it can be seen that volumetric fog takes around 30ms in newer unity versions, and just about 3ms in 2018.3

Edit 8: Disabling gpu profiling sets the render thread usage way down.
Closing the profiler entirely sets render thread usage down to about 3ms from around 18 MS in a testscene (Similar to disabling the gpu profiler), and cpu usage way down, too, giving me over 100 fps in that certain testscene, to around 60 with the profiler opened. There are many inaccuracies using the profiler and testing inside the editor at all​

​

 

I ran into this issue when trying to edit a Probuilder/Polybrush mesh, during which the Editor becomes unusably slow with 2-10 seconds per frame, time spent in Semaphore.WaitForSignal inside of Gfx.ReadBackImage.

Switching the Graphics API for Mac to OpenGLCore is a workaround.

I have submitted a bug report.

 

I just ran into this also. In this cast I'm using WeatherMaker, and when a "Light" property ("get_Light()") is accessed, it causes a 30.21ms delay waiting on Semaphore.WaitForSignal().

 

Same here, scene with nothing but only one generated mesh (that represent grid) with simple shader
cause fps drop from 60 to 4 on Android (editor and standalone show ~1000fps) I tried vsync on/off, change different shaders,burst safety checks on\off,switch different graphics api, and nothig helps. In profiler i saw gfx.waitforpresentongfxthread takes ~700 ms on OpenGLES, and now i see Gfx.endasyncjobframe takes ~300ms on Vulkan

UPD For clearness, not only this mesh in the scene, but enabling this mesh cause issue, if i disable this object evrything goes back to normal 60 fps on android

 

Having the same issue. What set it off for me was moving a couple variables (just storing some positions and rotation) from Start to OnEnable. The weird thing is I did this for two objects with virtually the exact same functions (don't ask), and it worked perfectly when this change was made on the first object, but cropped up immediately when made on the second object. Literally no other changes were made between between the addition of these two lines, save for simply clicking the play button in the editor. Even stranger, the problem now persists in the same two lines of code on the first object that it originally worked fine on.

Pre-post edit: Upon further testing, the issue on one of the objects was resolved by removing the 2 lines in question, saving the script without them and running in the editor, and then adding the 2 lines back in. Unfortunately, removing the 2 lines and even the method entirely did not resolve the issue on the other object. It just doesn't add up.

The issue has the appearance of randomness, so I'm honestly not sure if it's easily replicable with a simplified project. I would at least attempt to replicate it in a simplified project and submit a report, but due to other setbacks that cropped up last week, I'm now 6 days behind and simply can't afford to spend any more time on stuff like this, I have to move on. If for nothing else than my sanity.

If I do happen to catch up on the roadmap next week I'll try to come back to this.

 

Good news! Thank you

 

Been ripping my hair out trying to figure out why such a simple game like the one I'm making is struggling to push frames on Android. Thank you for validating my woes.

 

Was there ever a fix to this? I'm getting this same issue on Unity 2019.1.0f2 windows 10

 

I was having the same issue while testing in 2019.2.0b5, showing up as both:

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

But primarily the latter.

I successfully fixed it.

I did two things:

1. Rolled back to 2019.1. This was not downgrading; I manually updated my a pre-beta version to catch up. This did NOT fix it, which was terrifying. I'm still on 2019.1 now.
   
2. Then I upgraded my NVIDIA drivers, and that seems to have resolved the issue. I also upgraded all other drivers too but it's probably the NVIDIA ones that fixed it. So, try upgrading your drivers maybe that will help.

 

I been having the Semaphore.WaitForSignal issue in the profiler (hitting 80%+). This fixes both 2018 and 2019 versions for me on Mac. Simply docking shader graph, pro builder, and poly brush windows fixed it.

Shader graph if not docked would make my both my game and scene view unusable. Pro builder would crash unity if you zoom (f) on an object in a scene.

Also disabling metal editor in the project settings is a temporary fix.

 

I was having this issue and changing the game window resolution from 4k to 1080p seems to work (for now).

 

Have the same problem in 2019.1.3f and 2019.1.8f

 

I thought I had this issue in 2019.1.7 as well, until I looked closer at the profiler. Semaphore.WaitForSignal stood out, but it was just filling time created by too many physics updates. Turns out my fixed update rate had been set to 0.0001 by some asset, not at runtime but in the projectproperties :/ Just mentioning this in case it helps someone in a similar situation.

 

I am also facing the same issue with Unity 2019.1.5f1. Semaphore.WaitForSignal is taking too much time, I don't know what's happening. I'm currently building for Android.

 

current 2019 unity builds are very buggy on androids especially old models..

 

Hmm... interesting, I will test on 2018.4.3f1 which is the 2018 LTS, I will keep you guys updated.

 

there is something awfully wrong with unity 2019 + LWRP and android builds.. am getting lighting issues with bakes maps (they look black) .. the semaphore issue used to happen on my old android phones from 2 years and so... my galaxy s10 didn't have this issue.. so i thought this issue happens due to a bottleneck on old devices..

but now am getting semaphore issue on latest unity 2019.1.9f on LWRP on my galaxy s10..

this phone is a beasty graphical device.. i was able to use heavy shaders with vertex animations.. with post processing effects with real time shadows + baked indirect... and it was running like 57fps+ on unity 2019.1.8f on 2k resolution!

after upgrading to latest unity version. the build runs at half fps.. 25fps .. the semaphore thingie brought my s10 to it's knees.. this is definitely not normal.. especially that i haven't made any drastic changes to the project , in fact i disabled post processing + vertex animation shaders.. even when i lowered the dynamic resolution to almost half the resolution.. the fps was around 45!! didn't even climb to 60fps..



right now am trying multiple things to check why this issue happens.. i will try to report this issue.

 

2018.4.3f1 and 2018.4.4f1 both have the same issue. 2D development is absurdly slow.

 

the more i test the more i grow suspicious of dynamic resolution implementation in unity being the reason behind all abnormalities on different android devices. i've been using it recently and so far it was behind all performance issues.
CPU usage was climbing to 100ms sometimes, same issues but differs in severity on s10 , lenovo tab 3, pixel 1 , nexus 5x.. it happened even on the latest build (2019.1.10f).

on lenovo a scene used to be 60fps, with dynamic resolution it dropped to 18 fps,even i reduced resolution even less than previous resolution implementation when using setResolution.
i removed/unchecked everything related to dynamic resolution (camera/settings/scripts), and scene went back to 60fps.

i will try tonight to make a small build to see if i can reproduce the issue separately from my project. if this issue has already been reported/found by unity team, i will refrain from doing all this stuff.