I am facing a problem which a lot people seems to face since Semaphore is visible in the inspector. I am not sure if it is a bug, but I guess its just a misunderstanding of what is going on. We are currently working in Unity 2020.1.17 and building a tilemap based game to an android XCover4 (and other devices). Unfortunetly the Semaphore.WaitForSignal is blocking a lot of performance on the XCover4 (on fast devices it is a little better, but still there). The GPU runs with 100 FPS and if you turn off the GPU profiling the Semaphore.WaitForSignal peaks still high but it not so constant.
If putting VSYNC off, the Semaphore.WaitForSignal will be in the VSYNC group instead of rendering group
just default sprite shaders are used (tested with and without GPU Instancing)
if multithread rendering is off it is gone, but of cause the perfomance is worse
The shown CPU FPS in the inspector are the once which are visible on the smartphone aswell. I would have expected that the CPU Semaphore.WaitForSignal would kind of sync to the GPU FPS.
We are currenetly building a ingame none-dev. build FPS counter to have a look on the real FPS without a lot of other stuff going wild.
I will post updates later and am looking forward to get some good input!
Kind regards
I also just gave some more details on a similar thread:
To some of your specifics:
Enabling the GPU Profiler affects GPU performance, so seeing that lowering the frame rate is somewhat expected. The important number here isn’t the frame rate, it’s the time in ms, so that’d be around 10ms, possibly somewhat less when not GPU profiling.
Now with hat info, check out how your frame gets processed on the CPU via the CPU Usage Profiler Module’s timeline view. Look if you can trace how the frame is prepared for Rendering on the Main Thread, handed over for additional and multithreaded processing to the Render Thread, which is issuing commands to the GPU and then in Gfx.Present waiting on the GPU. Now this is where you can roughly insert those 10ms of GPU time. Then keep in mind that the GPU will have to hold on to the frame until the next vBlank every 16.66ms so that might add some additional margin. And check out in which intervals/at which moments within the frame these key handover points occure and why. That should help in building an understanding of what is going on and where and how to tackle this.
thank you for your complex respons! It helped me a lot to get deeper into the topic. I can see clearly now that is matches to the ms. To get a better feeling how our framerates realy look on the device, we have included a FPS counter in game, which shows 60 FPS. I will go deeper into the details based on your information, so I realy understand whats going on.
You’re welcome
Also, a bit of a side note but FPS is a tricky metric because its non linear, so an ms display might be an interesting alternativ as ms are linear. It just takes a bit of adjustment to think of your frame rate as 16.66 ms or 33.3 ms
Thats a interesting input aswell, with your link it shouldn’t be to hard to get into that way of thinking and it brings a lot more clearness into the topic. Thanks again!
