koobas.hobune.stream
Semaphore.WaitForSignal is causing so much lag on Android!!! Help!!!
Hi,
I have made a small and relatively simple 3D game that I want to upload to Google Play. I built the .apk to my phone for testing and in the beginning it went well. Playing went smoothly (60 fps) but after a couple of minutes I started getting about 35 fps. I noticed about 5 - 10 small spikes, then after a scene reload in the game, I was stuck at about 35 fps.
I did some investigating in the profiler and found that Semaphore.WaitForSignal seemed to be causing the issue.
Please help me!!!! Comment if you would like some images to clarify the issue!
Hi, I also ran into the same! I tried to switch to the default render pipeline and it worked for me!,hi, I have also the similar problem where I used URP. I tried static batching and dynamic batching but Semaphore.WaitForSignal is taking 43ms. so i decided to switch to the default render pipeline and god damn it worked for me! now my game is running 60 fps. so just try to switch to the default render pipeline in case if u use URP!
@soundarking i am not a hundred percent sure on this but I have encountered this once on an oculus quest project. Urp renders to a intermediate render target by default (called color buffer). In the editor this is necessary but in builds you can write directly to the swap chain render targets (which oculus recommends). The texture switch costs a lot of gpu time and almost always pushes you beyond the 90 fps ti$$anonymous$$g. If you feel comfortable editing the urp files it can be fixed though.
It's sad that switching back to built in is still so often the only fix for these kinds of issues :-/
I solved it
I changed my fixed timestep from 0.5 to 0.013333 which eliminated the lag
Semaphore.WaitForSignal is a process which does something similar as vsync. it synchronizes gpu and cpu. If you say Semaphore takes a up a lot of frametime this can mean two things unfortunately. Either you are well under your frame budget (and gpu/cpu wait for the device target frame rate) or you are above your framebudget and you are missing the sync point to hand over the finished rendered frame and you are waiting until the next sync point resulting in bad fps.
why changing the physics step to something lower fixed it for you is beyond me but this might help you understand more about what the semaphore does: https://developer.oculus.com/blog/understanding-gameplay-latency-for-oculus-quest-oculus-go-and-gear-vr/
