Bug iPhone 13 Pro 120hz, something is wrong with display synchronisation inside Unity

Hey! I have an app Fluid Simulation with +10m install base https://apps.apple.com/us/app/fluid-simulation/id1443124993?platform=iphone

I have a problem though. Sometimes the app runs perfectly at 120hz/fps then suddenly and randomly it gets locked to 60fps. Sometimes it gets unlocked to 120fps again.

In profiler it shows that time got spent on Gfx.WaitForPresentOnGfxThread, on display synchronisation or waiting for GPU. One can assume that it is a GPU performance issue but Xcode Profiler shows a different picture:

Here are stats when it runs at 120fps. Perfect!


And now when it locks to 60fps. Notice very low GPU and CPU load.


I'm using Unity 2020.3.33f1, it also does this on newer 2021.* versions

It happens totally randomly. Neither battery level of the phone, neither quality settings inside the app affects this. ProMotion is enabled in player's settings.

 

Here is more info from Unity's profiler attached to iPhone 13 Pro.

This is when it runs perfectly at 120fps. Only WaitForTargetFPS


This is when at 60fps. Notice Gfx.WaitForPresentOnGfxThread is taking all the time


And the last one is more interesting. It is also 60fps but have both WaitForTargetFPS and Gfx.WaitForPresentOnGfxThread evenly distributed

 

This could be the power management of iOS rather than Unity's synchronization issue. This person used cocos2d-x and sees similar behavior. https://developer.apple.com/forums/thread/695097

I'd recommend submitting a bug report to Unity so that they can get the attention and indirectly get Apple to look at it.

Edit: Here is an interesting quote on the Apple Developer Site:

 

Thanks, Neonlyte! Don't know if it is an Apple's issue. The game Thumper on iOS for example doesn't have this problem and can run at 120hz steadily and it wasn't made in Unity engine. Maybe they used some hack with UIView animations or something to force iOS to run at 120hz.

I've submitted a bug report, case 1425276

 

I'm also meeting this bug here with iPad Pro 2021. Exactly the same behavior. Normally my stuff is done within 1ms, and the profiler shows 1ms stuff and 6ms WaitForTargetFPS. But suddenly it gets through 60fps, or even spikes to 30fps occasionally. It is really weird.

Would you please share a link to the issue tracker so we can follow the progress? @PavelDoGreat

 

I can't give direct link as it would also share my email address. I can copy paste the conversation in images





You can send bug reports too. It will increase the chance of them finally reproducing the bug

 

I've just made my attempt. Report number is IN-7012. I have made the project so that it can be replicated with just a build and no extra inputs.

I also attached a video. Should be enough.

 

After a bit of digging I found that the code for synchronization is visible in the XCode project, search for `preferredFrameRateRange` -- you can find that in a #if ios 15 block.
I currently didn't find any information about how the dirty iOS internals govern the frame rates. I checked info.plist and the .mm files and unity seems to be doing nothing wrong.

 

Cool!

I've also found this and played with values. There everything seems to be right. It's something internal in the engine.

 

Update: My submission was accepted as reproducible. I'll update once I hear back.

 

Not sure if related, but in my game I have nasty frame drops specifically on iPhone 13 pro.

I have Application.targetFrameRate set to 60, and it works fine on older devices: iPhone11, iPhone XR, and even iPhone SE (2016). But on iPhone 13 pro there is a periodic (~ once per second) frame drop from 60 to 40s, and a noticeable hiccup. I haven’t profiled it all yet, and not sure if 100% related to this thread, but at least it’s the closest one I found so far.

 

Ok, just digged a bit deeper. The issue in my case is also with Gfx.WaitForPresentOnGfxThread. Although, the manifestation is different, instead of randomly dropping to some other frame-rate, I see crippling spike every 60th frame. Below are three screenshots of the profiler with some comments

1) First a "normal" frame. It's the same picture that I can see on iPhone 11 and iPhone XR: solid 16.5 ms (60 FPS) with most of the time spend in the WaitForTargetFPS.

2) At some point, there starts a "build-up" of WaitForPresentOnGfxThread



3) Finally, every 60th frame, there is a massive 30 ms peak of WaitForPresentOnGfxThread

 

An update. One thing that I must have mentioned is that in my case I was using URP pipeline for iOS. At the beginning I wasn't relating the problem with the render, however, then I found this thread https://forum.unity.com/threads/gfx-waitforpresentongfxthread-takes-long-time.967504/ and decided to just give it a try, and migrate to "legacy" built-in render pipeline. Miraculously, it worked, there are no spikes in URP on iPhone 13Pro or other devices.

 

Thanks but unfortunately, I've been using the built-in pipeline from the beginning.

 

Update: My report is now visible on the Issue Tracker. Feel free to follow the progress using this link:
https://issuetracker.unity3d.com/issues/ios-target-fps-is-ignored-on-iphone-13-pro

 

+1, I'm having the exact same issue. I've got a 13 Pro Max with precicely what you're describing here. I'm using Unity 2021.3.5f1 with the latest version of the URP. My heart sank when I saw how recent all of this was... hopefully they get it sorted soon. I voted on the issue on issuetracker.

 

Unity, why have you marked this issue as "By Design"? https://issuetracker.unity3d.com/issues/ios-target-fps-is-ignored-on-iphone-13-pro

I would like to have answers on why this problem is not fixable. Your explanation that it is performance issue doesn't count because this problem happens even in empty projects. Are there plans to fix it in a future?

 

I just messed around with Unity's Metal support code in the generated Xcode project. Try comment out the following code below and see if the 120FPS is stable for you. My reproduction project could maintain it easily (I did switch to use iPhone 14 Pro, so I am not sure what the behavior for 13 Pro would be):



Edit: I may have spoken too early. I did just see the reproduction project dip to 60, although not as often as before. I still do think this is because of the device difference, unless people here can test it for me.

 

Well seems like they reversed the decision and the issue is active again. Whoever made them do it (or themselves did it), I thank you.

 

Any updates? Same issue, it's special for 120hz I guess. I tried with 90 (but it limited with 80) and its working much better than 120. Still dipping 60 but not as often as before.

 

Up... Still having this issue on iPhone 14 pro. 120 fps at start, and then jumps between 60 and 120.

 

Can confirm, after switching this flag off iPhone 14 Pro can sustain 120FPS, no problem.

 

Sounds from the comment it may lead to input stuttering. Could you confirm or explain whether and why this will or will not happen?

 

First of all, I want to express my gratitude for you finally finding a solution to this problem. It gets fixed by setting ENABLE_DISPLAY_LINK_PAUSING to 0.

What does another line ENABLE_RUNLOOP_ACCEPT_INPUT does? If I set it to 0 what would change?

Code (CSharp):

1. #define ENABLE_DISPLAY_LINK_PAUSING 0
2. #define ENABLE_RUNLOOP_ACCEPT_INPUT 1

And give us more information on how it all affects input stuttering

 

I tried the solution. It is fine most of the times, but leads to seemingly infinite recursion on ipad mini 2 in some circumstances, which results in a stackoverflow and crashes thereupon:


It seems to be related with the other option.

 

I can also confirm that making ENABLE_DISPLAY_LINK_PAUSING and ENABLE_RUNLOOP_ACCEPT_INPUT 0, results in a much smoother 120hz experience.

I'm not sure if I want to release something with those settings turned off.

@Alexey has there been progress on checking the impact of turning those settings off?

 

@Alexey please check this thread https://forum.unity.com/threads/pro...ted-to-unity-2022-2-1f1.1380120/#post-8707044

Summarising, I've made an update to my app with ENABLE_DISPLAY_LINK_PAUSING 0. Also I updated Unity version to 2022.2.1f1. And started getting lots of `linearize_waiters` crashes on iOS. Then with next update I also did ENABLE_RUNLOOP_ACCEPT_INPUT 0 with no any other changes made to the app. And now crash count dropped 10x but still getting them.

 

Any update on the issue? Unfortunately:

#define ENABLE_DISPLAY_LINK_PAUSING 0 / 1
#define ENABLE_RUNLOOP_ACCEPT_INPUT 0 / 1

I tried billion combinations (pro motion enabled, disabled, changed these defines multiple times, both 0, both 1, separate values), no success.

Tried to use different Application.targetFrameRate, no success

Tried to use old input system, new input system, both input systems - again no success.

Used Unity 2021.3.30f1 LTS, Unity 2022.2.10f1, NO SUCCESS.

Everything not helping at all. Any time I'm touching the screen (on 120hz apple devices, e.g. iPhone 14 Pro), WaitForTargetFPS increases up to 27-30ms (so that fps drops to 30 instead of 60).

I can't complete App Review due to this issue, because Apple Reviewer is using iPad Pro (120hz) and he has these lags/glitches. It's extremely terrible, almost 2 weeks missed without any success... And I see the issue is still active, in summer will be 1 year ago since the issue was created.

Here is profile screenshot below. All spikes - I touched the screen on iPhone 14 Pro.

 

I found a small workaround to fix the problem. Unity above said to change few defines (it's not working in my case). But we have one more thing which could help. We can try manually edit
`Classes/UnityAppController+Rendering.mm' the following

OLD

Code (CSharp):

1. int maxFPS = (int)[UIScreen mainScreen].maximumFramesPerSecond;
2.     if (targetFPS <= 0)
3.         targetFPS = UnityGetTargetFPS();
4.     if (targetFPS > maxFPS)
5.     {
6.         targetFPS = maxFPS;
7.         UnitySetTargetFPS(targetFPS);
8.         return;
9.     }

NEW

Code (CSharp):

1. int maxFPS = (int)[UIScreen mainScreen].maximumFramesPerSecond;
2.     if (targetFPS <= maxFPS * 0.8)
3.         targetFPS = maxFPS * 0.8;
4.     if (targetFPS > maxFPS)
5.     {
6.         targetFPS = maxFPS;
7.         UnitySetTargetFPS(targetFPS);
8.         return;
9.     }
10.  

This really removes drops. I have added profile screenshot below. You can compare it with the previous message. In both cases I'm taping a lot.

NOTE: it works only if Application.targetFrameRate = 60 (120 has the same issue, drops to 60 even with "patch").

 

This fixed my issue and I now get less stuttering and a locked 120 fps on my iPhone 13 pro.

 

This issue is present on:
iPhone 14 Pro Max
Unity 2021.3.21f1
iOS 16.3.1

When targeting 60fps, I get stutter and framerate drops whenever I touch the screen. This is happening on both of my games. Neither one does it when deployed to Android devices.

The solution from Feelinside above does not work for me. Neither does setting
#define ENABLE_DISPLAY_LINK_PAUSING 0. I've also tried editing the info.plist as discussed elsewhere, which also did not help.

If this is affecting you, please vote on the issue here:
https://issuetracker.unity3d.com/issues/ios-target-fps-is-ignored-on-iphone-13-pro

 

It seems that Unity staff is in progress of refactoring the relevant trampoline code. At least since 2022.2.10, the ENABLE_DISPLAY_LINK_PAUSING flag is gone entirely, and code within ENABLE_RUNLOOP_ACCEPT_INPUT has been refactored into a boolean flag and is not actually used anywhere as far as I could find.

Side note, I did find that the Engine itself would enforce a frame rate cap. I accidentally discovered this through tinkering by calling "repaintDisplayLink" through native UI code. Even if native UIKit components renders at 120FPS by default, the Unity view would cause entire screen including native UI to still only render at 30FPS by default, unless Application.targetFrameRate is set to 120FPS. Calling "callbackFramerateChange:" directly through native code does not seem to work and the screen would still render at 30FPS.

If my understanding is correct, this essentially means that the Unity render loop is not entirely driven by CADisplayLink callbacks. I don't think this amounts to anything significant as it does not seem to interfere with anything, but it's still interesting to learn.

 

Just my 2 cents but while testing the

Code (CSharp):

1. ENABLE_DISPLAY_LINK_PAUSING

changes, it made my FPS fluctuate a lot. I save the minimum, maximum, average fps over a period of time and instead of having perfect ~59-60 for each values, I was now getting minimum at ~38-45. I would very much caution unity staff to properly tests those changes before changing them.

 

This stuttering on input does not happen on my iPad mini 6th gen, which is on iPadOS 16..3.1. Maybe because it doesn't have pro motion?

 

2021.1.28, pretty sure I tried with and without `ENABLE_RUNLOOP_ACCEPT_INPUT` with the same results

 

@Alexey Could you help check on IN-7012 that initially reported this issue? It was closed by a Unity staff today saying that this was a “device-specific issue” which must not be true because you have already identified a workaround in the Unity code. I see that UUM-5944 is still open on issue tracker. What is going on here?

 

"Device specific issue" is such a great reason for closing.

I wonder if they use it for bugs that affect consoles.

"Ah, this issue only happens on PS5, therefore we're closing this bug".

 

This is even more confusing. The "ENABLE_RUNLOOP_ACCEPT_INPUT" was not even the relevant cause of the 120FPS issue we discussed here.

This thread is about the 120FPS issue on iPhone 13 Pro and iPhone 14 Pro. The fix/workaround was about "ENABLE_DISPLAY_LINK_PAUSING" (see the quote above by @Alexey, a Unity staff on this exact thread Dec 21, 2022), and it did actually fix the 120FPS issue for me (and not only for me), which was the reason I submitted issue IN-7012 (UUM-5944) to begin with (see post I made also on this thread much earlier on Jun 14, 2022). Are you saying that the 120FPS issue I reported is not fixable by Unity when there IS already a fix provided by Unity months ago?

For the record "ENABLE_RUNLOOP_ACCEPT_INPUT" was only mentioned since this post on Dec 25, 2022. The workaround post by @Alexey (again, on Dec 21, 2022) did not mention this particular flag whatsoever.

 

And taking a step back, the fix that resolves this 120FPS issue was already implemented when I looked at 2022.2.10, so at least mark my issue as fixed?? Why say a fix is not possible when that fix has already been implemented?

Quoting myself:

 

To be fair, this was never my intention, and QA heavily modified my original submission to what you ended up seeing. In my original submission, the main focus WAS on the 120FPS issue, and tapping on the screen was just one minor observations I encountered out of desperation when troubleshooting this issue myself, and I thought it would be interesting to briefly mention this. I wasn't sure why QA ended up rephrasing my post to make it sounds like that "tapping on screen" was the main concern. See the screenshots of my additional comment at the time that survived the description rewrite by QA. I even posted a YouTube video and I wasn't tapping the screen in there. :/ (Jun 14, 2022)

Anyhow, the goal for me when submitting the issue was to bring your attention to the 120FPS issue, and it has been achieved. I can rest easy. It's just that I spent effort putting the submissions together and I don't want it to be ended up misinterpreted.

 

One more thing I do want to comment on is the whole streak of events were very odd to begin with, and could have been avoided. I saw that Unity adopted the new Info.plist key and the new frame rate range API shortly after iOS 15 and iPhone 13 Pro came out. I don't know if you guys have done more tests beyond just adding in the API in the code, but the fact was that we ended up having this issue for more than a year until the newer iPhone 14 Pro was already out for a good few months before a solution was provided. OP's submission was rejected as not reproducible, my submission was closed once as "by design" before it was reopened. It's just wasn't pleasant having to deal with this.

 

It’s indeed unfortunate, but although I don’t like what QA did to my submission, I won’t dwell on this.

No, not at all. That was all the fix I needed for my issue. The silver lining was that I gained quite a bit of insight into this repaint interaction with CADisplayLink.