Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  2. Ever participated in one our Game Jams? Want pointers on your project? Our Evangelists will be available on Friday to give feedback. Come share your games with us!
    Dismiss Notice

WaitForTargetFPS happening with unlimited TargetFrameRate in iOS

Discussion in 'Editor & General Support' started by roberto_sc, May 22, 2019.

  1. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    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:

    Screen Shot 2019-05-22 at 3.39.27 PM.png


    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?
     
    Last edited: May 24, 2019
  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
    Which exact Unity version are you using and what is QualitySettings-vSyncCount set to? Also, What generation of iPad are you profiling?
     
  3. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    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.
     
  4. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    @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.
     

    Attached Files:

    Last edited: May 24, 2019
  5. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    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.
     
  6. martonekler

    martonekler

    Unity Technologies

    Joined:
    Feb 5, 2015
    Posts:
    31
    Hi, could you please file bugreport with a small repro?

    Thanks,
    Marton
     
  7. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
    @roberto_sc sorry for the longer wait on my reply. So, judging by Marton's reply, it looks like this might be buggy behavior of our rendering code on iOS. BTW, which graphics backend are you using.

    Also, I've seen some users having issues with multi-threaded rendering on mobile, maybe try turning that off and see how things change. Note that that would likely mean it's a bug that should be reported and that that shouldn't be taken as general advice but something to try to isolate, where the issue lies.

    And yes, I've seen other users experience that too: that slipping by the 16.66 ms mark means they'll fall through to the 33.33 ms mark.

    Was this still on 2019.1?
    We've recently fixed how "Other" was calculated rendered to the charts, I'd have to check again where exactly that fix landed. Also, "Other" is currently hidden by default and only calculated and shown as overlay if a sample is selected (where the overlay will then highlight how much time was spend on that sample and anything below it across the different categories and all 300 frames). You could select the "PlayerLoop" sample and it should add the graph for the "Other" category. Annoyingly, gray samples such as "Unaccounted time" and "Semaphore Wait for Signal" currently gets thrown in with the "Other" category. Also, which Category gets how much time allotted to is defined by the category of whichever sample is on the top of the stack at any point in the main thread.

    to summarize, the gap between timeline view in the CPU chart is probably due to "Other" not being shown. Also, fixes for Charts have landed in 2018.3.9f1, 2019.1.0b9, 2019.2.0a11, 2019.3.0a2.

    Additionally, if the spike is to steep, the tip might get aliased away for a couple of pixels.
     
  9. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    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.
     
  10. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
    The way I understand @martonekler, this is a bug. I guess I just tried to say that I have seen people struggling with this before though.
    EDIT: this is NOT a bug. All mobile platforms can only present on a VBlank, i.e. run at an FPS equal to their their screens refresh rate or the their refresh rate divided my an integer. An update for the documentation for Application.targetFrameRate is on it's way.



    Also, just because something might be known as an issue on the forums, doesn't mean it reaches the right teams so that it is getting fixed. So if there is something off, even if people offer work-arounds, filing a bug report is the surest way to get it resolved for good. So thank you for your bug report :)


    Sorry, which feature are you referring to? The one where "Other" is only shown when a sample is selected that spends time in the "Other" category?
    If so, that is not technically a feature but more like a design flaw that needs fixing. I've created a bug report for it so that we don't forget to fix this.
     
    Last edited: Apr 30, 2020
    roberto_sc likes this.
  11. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    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...:oops::D
     
  12. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
  13. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    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?
     
  14. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
  15. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
    Yeah it is being looked into. There had been a bit of a misunderstanding by the QA person looking for a repro, but it is getting re-processed.
     
    roberto_sc likes this.
  16. roberto_sc

    roberto_sc

    Joined:
    Dec 13, 2010
    Posts:
    139
    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.
     
  17. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
    Hi @roberto_sc,

    As I've replied to you on the bug ticket, I've reopened the ticket and tried to clear up some of the confusion on there so that this can get looked at from a cleaner slate again.
    So just to clear some of this up in here as well for others:

    Code (CSharp):
    1. When using iOS build the iOS ignores “Don’t Sync” and instead uses “Every Second V Blank”.
    This is indeed wrong information. Yes, it will ignore the vSync setting, but instead it will just flip the frame at whichever vBlank is the first one after processing of the frame and waiting for the targeted frame rate is done.

    I'm in the process of updating the documentation to reflect that.
     
    Last edited: Mar 9, 2020
    roberto_sc likes this.
  18. deverolirc

    deverolirc

    Joined:
    Jan 19, 2014
    Posts:
    553
    Is this public on the issue tracker? Has a fix been released?
     
  19. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
  20. libin_hope

    libin_hope

    Joined:
    May 4, 2017
    Posts:
    2
    When can I fix it? Set targetframerate = 60 to reduce FPS
     
  21. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    627
    I'm sorry, I don't get what you mean with either of these sentences.
    Just some thoughts though:
    1. make sure that this precise issue is what you're experiencing. There's a very high chance you are looking at something similar but quite different. Please check the Profiler documentation on custom samples for things that commonly cause confusion.
    2. If you're not sure, consider opening a new thread
    3. If it IS this issue, I don't think you can fix it until we fixed it. You can check that issue tracker link above every now and then to see if it is resolved though.
     
unityunity