Semaphore.WaitForSignal causing performance issues?

I am making a 2D Android game and the profiler is showing Semaphore.WaitForSignal as the root cause for a high CPU rendering (about 9.7ms), but it shows up a lot.

What is Semaphore.WaitForSignal?
What could I do to improve performance?

 

I think this means something in your Graphics pipeline is waiting for something else to finish. Usually it means rendering is taking a while to finish, and some other part of the graphics pipeline can't proceed until rendering is complete.

Try replacing any complex shaders with very simple/unlit shaders, and see if the issue goes away. Make sure you also don't have huge amounts of overdraw. (Eg overlapping transparent textures covering large amounts of the screen)

 

Thanks for the reply!

I should mention that this is strictly UI. I know for a fact that the shaders are not the problem (default UI shader), and I've only got five draw calls. My UI elements, however, all have large amounts of transparency.

I have a feeling that this might be a problem...

 

If the GPU takes way too much of the frame time compared to the CPU, the main thread will have to sit and wait for the current frame to finish rendering before it can start preparing the next one. To confirm if that is the case, lower you rendering resolution to see if the timings change at all.

 

Thanks for the help!

But how do I lower the rendering resolution?

 

Thanks for your help!

This is a sample of my game running idle on a physical Android device. I can't seem to figure out what is halting the thread?

 

Hello,
I've tried enabling Optimized Frame Pacing and disabling Graphics Jobs in my PlayerSettings, but this only increased VSync in the profiler.

 

Thanks a lot for the help so far, but I still can't seem to nail down what's happening on the GPU side of things.

My phone has a Qualcomm Snapdragon 820 in it, so I tried using the Snapdragon Profiler from Qualcomm. But it doesn't provide any useful info about the GPU. I've tried some other things, but they were no help as well. I don't have access to an Android device that can be profiled within Unity...

Any suggestions? What would you do?

Thanks, once again.

 

Switched to OpenGL and turned off graphics jobs. Not much of a difference, but I did file a bug report before I switched.
I can't thank you enough for the help! I think it's time to finish this thread here...

Thanks, once again

 

Hi mate good morning do you have a still same problem or did you fixed it if you could you tell me how did you fixed

 

Hello Batuhan13.

Like I mentioned in my posts above, I've filed a bug report to Unity and they were able to find the bug.
As far as I know, the bug is still not fixed because I still see it in my profiler.



Also, I keep track of the release notes, and I still haven't seen it there.
What I recommend, from my own experience, is that you try to optimize your game as much as you can, so that it can run as efficiently as possible. Also, make sure to always use the latest version of Unity.

Not much we can do for now, but I hope this helps.

 

In case it's of use to someone... been struggling with this while profiling a Quest2 app via adb (i.e. running a development build) As soon as I ran a normal build, just on the headset, everything was suddenly running as expected with no spikes (at least no FPS variations that could be seen in the Oculus Debug Tools overlay.)I guess it's the equivalent of the Editor overhead but in a development build with script debugging. (Unity 2019.4.15)

 

Is there any news on this issue and the bug report?

-Pieter

 

+1 its much worse for me ,i am using large 200x200x200 compute shaders and rendering around 30k cubes with a simple instanced material,i also found that the gpu profiler is reporting large spikes with something called "Action 1.Invoke()[Invoke]" which i think relates to this code void calculatevalid(){ for (int i = 0; i < curp.Length; i++) //10ms ! - Pastebin.com

 

I figured out what was causing the Semaphore.WaitForSignal


I was running a test build of my Android game to my Samsung smartphone and I wanted to profile the game running on it. To do this I connected my smartphone to my computer via micro USB (charging cable) and ran the profiler.

I didn't know that there is actually a way to profile your game on an Android device wirelessly rather than connecting your smartphone to your computer with a cable.

In the build settings of my project, I had an option called "Autoconnected Profiler" turned on. This meant that I was profiling my game wirelessly even though I thought I was profiling it through the micro USB cable.

The profiler is collecting real-time data through wifi. This was naturally causing large delays (or spikes) in the profiler as Semaphore.WaitForSignal.



All I had to do is turn off Autoconnected Profiler in the build settings of my project. Then when I profiled my game on my smartphone with a micro USB cable, the Semaphore.WaitForSignal was gone or at least A LOT less noticeable.





Hope this helps and thank you to all for offering your time and support!

 

Problem is still there, and is there since years, it pops up randomly, my first guess would be it is a bug.
This is supposed to be an empty scene (unity template, Camera+Light), thus no special shaders in use.

Can't debug further, I'm on mac, no Vulcal support. Have no access to a Windows machine.
But searching online seems there is a lot of related posts.
Unity 2020.02.5f1.
Tried with and without deep profiling, and with the standalone one, call is always the same, repeated every few ms like in pic.

 

I'm getting the same issue with 2020.3.3f1 HDRP 10.4


As you can see that the issue isn't continuous here

 

I just noticed it is possible to profile the editor alone (menu is on the top left). There seem to be a spike with a similar profile to the one I posted with the semaphoreWait in the player profiler.

It could be something editor related, I didn't notice it in the builds.
For sure the call on the Timeline/Hierarchy should be more informative, this is just very confusing.

 

SOLVED (for me) :
I updated the graphics card's driver and everything works just fine again.
The "Semaphore" thing spread up to 60 ms since yesterday out of nowhere.

 

I'm also seeing similar issue, also on a mac. Fairly new to looking at the profiler and wondering what might be a proper way of tackling this issue. version 2021.1.3f1c1

 

@ocholicious +1

 

Hi ,

I am facing similar issue in Unity 2020.3.5f1 with URP in MI A1 device, but it works fine in POCO X3 and Nokia 5.3 and OnePlus Nord, In MI A1 I am getting 15 fps and in all other devices I am getting 50+FPS, when I checked the profiler it was showing Semaphore.waitforsignal is taking 60ms in each frame.

So I Tried with an empty Unity project (URP) in MI A1 I faced similar issue I got 20FPS For the URP SampleScene



Specs For MI A1
GPU - Adreno 506
RAM- 4GB
Shader Level : 45
CPU: ARM64 FP ASIDMD AES [8 cores]

Thank you.

 

Hi,

I'm facing the same issues on Android / Vulkan with 2020.3.11 and URP.

Even the simplest scenes only have 15 fps and the profiler shows Semaphore.WaitForSignal taking 60ms in each frame.

 

Hi all. Is it possible that other factors affect semaphore.waitforsignal?
Here, draw and setpass calls and tris and vertices count don't increase much but semphore skyrocketed. What can be the reason?

One more question, if I use complex shaders, where the cost add up? Does it increase semaphore or camera.render?

 

Okay got it thank you <3

 

Hi guys. I have a similar issue on a very popular hand-held device.
GPU takes 11ms (regarding Unity Profiler and the manufacture's GPU debugging tool) to render everything and the CPU 20ms. The 20ms on the CPU is mostly caused by Gfx.WaitForPresent which makes no sense for me? Or do I misunderstand something? The CPU should only wait for the GPU if we would be GPU bound, right?

We are on Unity 2020.3.9f1, URP 10.5, SRPBatcher on with only a few draw calls (<100).
My suspicion is that the SRP batcher is eating up the CPU time, could that lead to something?

 

Never mind, it was that one specific platform debugger which caused the CPU load.

 

I also encountered a similar problem but it was due to my CPU. Enabling the GPU skinning in Project Setting solved my problem.

 

When I encountered this issue,
I mistakenly put GetComponent<GameScene> in Update(), and that caused Semaphore.WaitForSignal.
I transferred GetComponent under Start(). and solved.

I recommend to check shortly before Semaphore.WaitForSignal in "Timline" of CPU usage.

 

Hello, In my particular case I was having the same issue with this. I found out that (in my project) was the shaders of some tree models that was causing the issue. The GPU was taking too long to calculate the shading for these models. Disabling them caused to make everything works fine again.

 

[SOLVED for me]
Hello everyone,

I was working on android build, also I read various thread about same issue and most of people are working on android build. I thought it maybe related with android then I found below solution while I'm trying different things.

Cause: "Device simulator" is in the project and there was open 'Simulator' window in editor. Even if it is not actively used window, it affected performance in my case.
Solution: I turned off 'Simulator' window and long duration of Semaphore.WaitForSignal is decreased to around 3ms.

Still don't understand how "Device simulator" affects the meaningless waiting time but it worked for me, I hope it may help you too.

P.S. this was my first post in this forum, love you guys

 

I had those Semaphore.WaitForSignal spikes coming and going... Seems like I had big game objects that had shaders with no textures on them. Applying a texture to them seems to have fixed that problem.

 

I also met this issue.Solved program:Unplug the airpods from the usb.Maybe the drive cause

 

After changing the setting described in the link below, the problem went away for me.
Is it possible this is the issue:
https://forum.unity.com/threads/ple...mode-monitor-refresh-rate-by-default.1353761/

 

Unity 2019 had "sync to monitor" as the default interaction mode setting, Unity 2020 & Unity 2021 have "default" as the default setting, which is "run as fast as possible" - even if the scene is empty. This is a huge change and confusing a lot of users. The default is now an advanced user setting, instead of a user friendly setting like sync to monitor (which I imagine is what most people would want, and actually used to be the default).

Interaction Mode is applied if Game > Vsync is ON (according to the Unity docs) in play mode.

 

I had troubles with this also and I found your suggestion promising. Although the settings had improved performance, it was the Selection Outline gizmo, in my case, that caused the low frame rate in the Editor, as I explain here.

 

Hi, I have this problem too. I did many shaders and all works good, but now i have performance problems.

My project is 2D, URP, Unity 2021.3.15f1

I did a lot of proofs, and only 1 shader give me problems, so I create a new empty project, and have same problem. I have this shader:



When I connect Simple Noise to Alpha, i got drops from 60 to 30 fps all time:



In the scene I only have camera and Sprite with the shader:



So why CPU is waiting GPU¿?¿?¿? Drop exact to 30 fps, always 60 to 30 fps

I have many shaders more complex and all work good. This happen only in Android Build, I test in Xiaomi Redmi Note 7 Pro, Version MIUI 12.5.1 with Android Version 10

Somebody knows whats happen?

 

I create the project with BUILT IN and same happens

 

If shader is executed in image that takes up the entire screen I got bad performance, but if the image is small it's ok....

 

Instead of using Simple Noise, I create a texture to do noise and works perfect and got same effect

 

Hi there, sorry for the necro. But this thread is one of the top results when googling. Here's how I fixed mine, apparently the resolution in the game view is set to 4k. Setting it back to Full HD fixed the issue for me.

Good luck!

[EDIT - April 24, 2023]

We use a lot of render textures in our game. I experienced this again but choosing the correct Color Format and Depth Stencil Format for the render texture fixed the spikes.

[/EDIT]