Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Join us on Dec 8, 2022, between 7 am & 7 pm EST, in the DOTS Dev Blitz Day 2022 - Q&A forum, Discord, and Unity3D Subreddit to learn more about DOTS directly from the Unity Developers.
    Dismiss Notice
  3. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Semaphore.WaitForSignal causing performance issues?

Discussion in 'General Graphics' started by Ljaljevic1120, Feb 8, 2020.

  1. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    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?
     
  2. Arycama

    Arycama

    Joined:
    May 25, 2014
    Posts:
    179
    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)
     
    ltomov and richardfu71 like this.
  3. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    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...
     
  4. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,524
    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.
     
    Last edited: Oct 20, 2022
    pappapierre likes this.
  5. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    Thanks for the help!

    But how do I lower the rendering resolution?
     
  6. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    Just a sidenote but: Semaphore.WaitForSignal can't cause performance issues because it's literally just waiting for another thread. So what's causing the issue is on another thread and possibly originates from workload of a previous frame.

    Check out what happens in other threads in parallel using Timeline view and check out the Common Samples section of the CPU Profiler documentation.

    (We're working on improving the UX in the Profiler to guide towards the actual issue)
     
    RedRockRevolution likes this.
  7. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    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? Profiler Screen Shot.png
     
  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    Right so you're on 2019.3 and using Vulkan? Are you using an SRP?

    Anyways the Semaphore on the main thread gets triggered under a sample that tells you it is waiting for the Render Thread. The interesting samples are the ones on the Render thread that correlate to the beginning and the end of the wait, and a bit too small to read in the screenshot. I must admit that the long pause in between without any sample on the render thread looks suspiciously like a bug to me, at the very least it's missing a profiler marker. So that'd be worth filing a bug report for.

    As to what actually happens, I'd guess, since the Vulkan submit thread isn't doing much of anything, the stall is on the GPU side. I'd test what happens if you change the Application.targetFramerate and QualitySettings.vSync values and try to find a native platform Profiler from the GPU manufacturer of the GPU in your phone (Unity doesn't currently support GPU profiling when using Vulkan).
     
  9. florianpenzkofer

    florianpenzkofer

    Unity Technologies

    Joined:
    Sep 2, 2014
    Posts:
    467
    We are probably waiting for the next Vulkan backbuffer/swapchain image in the large gap.
    Even if that's the case we should improve the profiler output. Feel free to report a bug with repro project.

    If you want to avoid the spikes you can try to enable "Optimized Frame Pacing" in PlayerSettings.
    You can also try to disable Graphics Jobs in PlayerSettings. Typically Multithreaded Rendering without Graphics Jobs is the best compromise on Android, across different games and devices.
     
  10. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    Hello,
    I've tried enabling Optimized Frame Pacing and disabling Graphics Jobs in my PlayerSettings, but this only increased VSync in the profiler.
     
  11. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    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.
     
    DayunKim likes this.
  12. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    You could switch to OpenGL and turn off graphics jobs. That should be profilable with Unity's GPU Profiler. Then again, at this point your profiling different behavior as it's a different graphics Backend.

    Also, before you switch, please consider filing a bug report so that this gap can be investigated and fixed by us.
     
    Last edited: Feb 16, 2020
  13. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    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 :)
     
    richardkettlewell likes this.
  14. Batuhan13

    Batuhan13

    Joined:
    Apr 9, 2017
    Posts:
    117
    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 :D
     
  15. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    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.

    Screen Shot.png

    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. ;)
     
    Batuhan13 likes this.
  16. jeromeWork

    jeromeWork

    Joined:
    Sep 1, 2015
    Posts:
    412
    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)
     
    uniteiro likes this.
  17. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    Yeah, to profile closer to release performance, turn off script debugging.
     
    jeromeWork likes this.
  18. PieterAlbers

    PieterAlbers

    Joined:
    Dec 2, 2014
    Posts:
    212
    Is there any news on this issue and the bug report?

    -Pieter
     
    Game-Savvy likes this.
  19. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    I don't have an issue ID for that bug report so I can't check that report directly and all bugs I can find searching for Optimized Frame Pacing seem closed but maybe @Ljaljevic1120 still has the issue ID handy for us to check. If this is still an issue for you on the latest patch version of the Minor Unity version you are on, it might be best to file a separate bug report on this.
     
  20. dkaloger

    dkaloger

    Joined:
    Jul 7, 2019
    Posts:
    39

    Attached Files:

    Last edited: Apr 18, 2021
  21. Ljaljevic1120

    Ljaljevic1120

    Joined:
    Jul 15, 2019
    Posts:
    85
    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.


    Screen Shot - Build Settings.png


    Hope this helps and thank you to all for offering your time and support!
     
    Perocket, Sammonius, igorper and 2 others like this.
  22. WBonX

    WBonX

    Joined:
    Aug 7, 2018
    Posts:
    15
    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.

    upload_2021-4-20_10-25-4.png
     
    dot_entity likes this.
  23. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    885
    I'm getting the same issue with 2020.3.3f1 HDRP 10.4
    upload_2021-4-20_15-30-29.png

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

    WBonX

    Joined:
    Aug 7, 2018
    Posts:
    15
    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.
     
  25. timodamasc98

    timodamasc98

    Joined:
    Sep 8, 2020
    Posts:
    1
    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.
     
  26. ocholicious

    ocholicious

    Joined:
    Mar 9, 2016
    Posts:
    8
    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
     

    Attached Files:

    dot_entity likes this.
  27. scrant

    scrant

    Joined:
    Jun 1, 2017
    Posts:
    66
  28. akshith_s

    akshith_s

    Joined:
    Apr 26, 2021
    Posts:
    3
    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

    upload_2021-6-11_10-39-44.png

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

    Thank you.
     
  29. big_3

    big_3

    Joined:
    Apr 20, 2016
    Posts:
    70
    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.

    upload_2021-6-30_23-32-0.png
     
  30. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    @WBonX, @Akshith_PTW and @big_3, please each of you file a bug report for your individual issues. I can't be certain they are bugs in unity, issues with your specific device or project, but there's a chance and it's impossible to tell from this thread without a repro project and proper bug report.

    Ideally also see if you can use Android Studio, Arm Mobile Studio's profiling tools or other platform or GPU manufacturer specific tools to check the GPU load on these devices, to double check that you aren't just GPU bottlenecked for some reason.

    @dkaloger I suspect that compute call might be taxing your GPU too much or otherwise infers with it's workload. The advice to look at specific tools for GPU profiling holds here too.
     
  31. Mashti

    Mashti

    Joined:
    Feb 19, 2019
    Posts:
    2
    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?
    Screenshot 2021-07-18 224259.png
     
    Last edited: Jul 18, 2021
  32. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    Shader complexity affects how long the GPU takes to compute the results, which shows up on the CPU side as Gfx.WaitForPresent (...OnGfxThread). So I guess the change you had was heavier on the GPU side then on the CPU Rendering side, which is more affected by calculating and gathering batches to send them over to the GPU.
     
    senkal_ likes this.
  33. Mashti

    Mashti

    Joined:
    Feb 19, 2019
    Posts:
    2
    Okay got it thank you <3
     
    MartinTilo likes this.
  34. goran_okomotive

    goran_okomotive

    Joined:
    Apr 26, 2017
    Posts:
    59
    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?
     
  35. goran_okomotive

    goran_okomotive

    Joined:
    Apr 26, 2017
    Posts:
    59
    Never mind, it was that one specific platform debugger which caused the CPU load. o_O
     
    MartinTilo likes this.
  36. shouchongMaster

    shouchongMaster

    Joined:
    Jul 5, 2020
    Posts:
    1
    I also encountered a similar problem but it was due to my CPU. Enabling the GPU skinning in Project Setting solved my problem.
     
  37. zakuro1234567

    zakuro1234567

    Joined:
    Jun 15, 2021
    Posts:
    1
    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.
     
  38. erickluiss

    erickluiss

    Joined:
    Feb 20, 2020
    Posts:
    8
    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.
     
  39. Kollektor

    Kollektor

    Joined:
    Apr 11, 2020
    Posts:
    1
    [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 :)
     
    Camad likes this.
  40. jo82

    jo82

    Joined:
    Dec 3, 2015
    Posts:
    37
    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.
     
  41. wencc

    wencc

    Joined:
    Apr 16, 2018
    Posts:
    1
    I also met this issue.Solved program:Unplug the airpods from the usb.Maybe the drive cause
     
  42. hawken

    hawken

    Joined:
    Aug 22, 2013
    Posts:
    759
    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/
     
    Last edited: Nov 5, 2022
  43. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,870
    Well yeah? If you run as fast as possible and are GPU bound, the CPU will wait on the GPU and show this marker.
    If you are switching the interaction mode to Refresh rate, you wait for the refresh rate on the CPU side (because the Editor doesn't do actual VSync on the GPU). Afaik the interaction mode setting does not apply to Playmode though...
     
  44. hawken

    hawken

    Joined:
    Aug 22, 2013
    Posts:
    759
    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.
     
  45. dot_entity

    dot_entity

    Joined:
    Nov 2, 2012
    Posts:
    57
    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.