WaitForTargetFPS happening with unlimited TargetFrameRate in iOS

I'm seeing WaitForTargetFPS happening on iOS. Application.TargetFrameRate is set to 60 but the game is running at 30 fps. I'm using Multithreaded Rendering.

This is what I'm getting in profiler:




It feels like WaitForTargetFPS is waiting for the render thread, which doesn't make sense but I saw some people saying otherwise and also why would the main thread wait if the target is 60 fps and render thread is free?

 

Hi! I'm using Unity 2019.1.3f1, VSync count is set to zero (but I thought this wouldn't matter for iOS?) and I'm using an iPad Mini 4.

 

@MartinTilo sorry for spamming.
I went over this again to verify I was doing everything correct. I'm printing my Application.TargetFrameRate every 5 seconds and it is indeed 60, VSync = 0. I can achieve 60 in other parts of the game (main UI, etc) but during gameplay I get a steady 30fps with a lot of WaitForTargetFPS.
I can't find anything related to it in Instruments.
Is there anything else that would cause a WaitForTargetFPS?
This is driving me nuts as I need to optimize this game asap.

By the way, originally I was using Unity 2017.4.24f1, I was getting "Unaccounted time between..." (please check new screenshot I posted), and that was the reason that lead me to upgrade, after some googling on the issue.

Also, how come doesn't the graph match the time line? I get around 33ms in most frames but the graph hardly reaches 30fps.

 

I disabled some renderers during gameplay and it goes to 60fps - except for a few frames where they still take 33ms. My conclusion is that if a frame can't be drawn in 16.6ms WaitForTargetFPS runs to make it take 33ms.

It would be nice to have a confirmation that it works this way. I don't remember seeing this behaviour in other projects.

 

@martonekler ticket number 1159050. Thank you.

 

Hello @MartinTilo.
I'm using Metal and Multithreaded Rendering. With Multithreaded Rendering disabled I get the same behaviour, that is, WaitForTargetFPS runs to fill the 33.33ms frame.

I'm sorry, but there's one thing I don't understand 100% in your response: you said that slipping by the 16.66 ms mark means they'll fall through to the 33.33ms mark. For me this sounds like you are saying it's the expected behaviour. Is it a bug or not?

Thanks for the explanation on the gap between timeline view and CPU chart, that's exactly what's happening. But I must say I find this new feature... weird.

 

I see now, thanks. But what behaviour did you expect then? I'm asking because if I understand correctly in iOS we are locked to 60fps or subdivisions of 60 to match the screen refresh rate. Would you expect another method to run to complete the 33ms window instead of WaitForTargetFPS?

Also feels like a bug because in a few cases it seemed the frame had enough space to run in a 16.66ms window but it took 33.33ms anyway (that is, WaitForTargetFPS ran for longer than 16.66ms). Unless measurements in profiler aren't 100% accurate or the budget is actually a bit less than 16.66ms.

haha ok, I see now. Phew...

 

Is this bug ever going to be looked into?

If I understand correctly, the renderer is not rendering on every single frame that it could, thus dropping FPS average a bit. Isn't this kinda... MAJOR?

 

@MartinTilo ^^

 

Hello @MartinTilo and @martonekler

I've got some answers from the QA team and I've decided to post them here because I'm getting a bit confused. Please bear with me and read on; this was their first answer:

I explained them that QualitySettings.vSyncCount is set to zero, which means "Don't Sync". Then they said:

This is just wrong.

Can you please take a look at this with the QA/dev team, or explain to me what I can't understand? Basically, these are my premises:

1. iOS does not ignore Don'tSync and uses "Every Second V Blank" instead;
2. the repro project that I sent for issue id 1159050 has a slider where the tester can use to make the frame take longer and verify the framerate dropping from 60fps to 30fps when the frame is still taking less than 16.66ms. This issue has nothing to do with vSync settings as the frames drop without changing any settings, but they will only find this out if they ever run the repro project.

Thank you.

 

Is this public on the issue tracker? Has a fix been released?

 

When can I fix it? Set targetframerate = 60 to reduce FPS

 

Sorry but after so many information im not sure anymore, Is this related with the bug you linked here ?

Im building on a MAC for iOS, using Unity 2019.4.12f and as you can see the WaitingForTargetFPS is always there using 15ms - 20.10 ms, even with the VSync set to don't sync.
Also, the moment this frame this capture is taken the Application.targetframerate is set to 30.

This is because during the game we switch to 30-60 depending on what the player is doing, if he moves, we set to 60, if he is still, we set to 30.



Is this part of the bug? also, why if the VSync is off this yellow graph appears when I check the VSync checkbox in the profiler?


Should I file a support ticket or this is the bug you are talking about ?
Thanks in advance.

 

It has NO effect at all? we set it to 30 because if we kept it to 60 all the time the device (iOS) seemed like it gained temperature and lowered fps considerably when playing for 15-20 min.... are you telling me this was not the reason? or maybe this WaitForTargetFPS it doesn't cause so much overhead as keeping it at 60fps ?

Thanks for your help.
pistoleta

 

I see, I understand now, so this is the normal behavior... vSync waiting times in iOS I mean. So I'm guessing we shouldn't be waiting for any kind of solution for this.

Thanks a lot for your help.

 

We have a huge problem with the iOS game when we use settings to run it on 30fps, the game is extremely jittery. But 60fps works flawlessly, something is very wrong. The game looks like it is running on 5-15fps, but it is showing stable 30fps.

To get 30fps we use:
targetframerate = -1 (locks game to 30fps)
vsynccount = 2 (not relevant, same behavior with any vsync due to iOS)
multithreaded rendering = off (because we found that it breaks vsync rendering on android)
Result:
On Unity 2017.4.32f1 and Unity 2017.4.40f1 jittery and unplayable.
On Unity 2019.4.13f1 works without any issues, normal users will hardly notice a difference between 30 and 60fps.

To get 60fps we use:
targetframerate = 60 (only way to get 60fps, -1 and vsync 1 gives 30fps)
vsynccount = 1 (not relevant, same behavior with any vsync due to iOS)
multithreaded rendering = off (because we found that it breaks vsync rendering on android)
Result:
On Unity 2017.4.32f1 and Unity 2017.4.40f1 works as it should, fluid.
On Unity 2019.4.13f1 drops every few seconds to 57-59fps.

We would move our project to 2019LTS, but there is a bug with terrain tree billboard rotation so that breaks all out vegetation.

Btw, we are not talking about very small screen tear/jitter that happens every few seconds and it is reported on numbers threads, for example, on this one: https://forum.unity.com/threads/tim...t-vsync-camerafollow-and-jitter.430339/page-7

 

Android
We always used just targetframerate to cap fps and made vsync optional to users, it was off by default. Our game is aimed at 60fps and interesting thing is that in 2017.4 (and 2018LTS) we have rock solid 60fps, but the same project on Unity 2019LTS can't keep 60fps, it bounces back to 58-59fps every few seconds and gets back to 60fps. We "fixed" it by setting targetframerate to 61fps, and that made it a solid 60fps. Something happened with targetframerate in Unity 2019. Check this post (with Android in mind), and link to another post in that post: https://forum.unity.com/threads/uni...-not-touching-the-screen.511902/#post-6366366.

Multithreaded rendering on Android makes the game stuttery/jittery, especially on 30fps with vsync on, it looks almost identical to the iOS 30fps jittery problem on 2017.4.

Once we solve issues with iOS which is a top priority currently I can get back to testing on Android and test fps capping with vsync and other things, for example, fps performance, stability, and smoothness degradation from 2017.4.7 -> 2018LTS -> 2019LTS but that is a topic for another thread (and there are already threads about this).

iOS
I can confirm that multithreaded rendering on 2019LTS does not produce stuttering.
On 2017LTS it looks as it makes things worse, I even suspected that maybe somehow multithreaded rendering was always on and it was breaking smoothness on 30fps, as it does on Android.
In the last few days, we made a few dozens builds with various settings in 2017.4 and didn't find any rational reason why this happens. I can again make some tests and provide you a profiler screenshot, maybe a whole project over bug report, but even if we determinate a bug what will happen? Unity 2017 updates are over as it looks.

With 2017.4LTS we get a rock-solid 60fps on our targeted device but if users have some older iPads with high resolution and they need to use 30fps, they will get a jittery unplayable game.
With 2019.4LTS we get a bit worse performance - unstable 60fps, broken tree billboards, but the 30fps issue and some iOS bugs are fixed.

I will test 2018LTS today to maybe mitigate these issues, but I'm afraid that this version could still have iOS bugs that were fixed in 2019LTS.

Terrain tree billboard bug on 2019LTS is reported: Case 1287879

 

@MartinTilo
We kind of lifted our hands from this issue, but due to other issues, we decided to include it in a detailed report. If you could take a look, there is interesting stuff about doubled CPU usage after ~150 frames on some Unity version, devices, fps lock, Jittering mentioned above, and more.

https://forum.unity.com/threads/uni...-proccesing-rendering-spikes-and-more.1056236