Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Question Big difference in CPU frame times between profiler and SteamVR.

Discussion in 'VR' started by roundyyy, Dec 31, 2022.

  1. roundyyy

    roundyyy

    Joined:
    Dec 23, 2019
    Posts:
    111
    Hello,
    I hope you will be able to help me. I'm struggling with very weird issue that I can't solve for couple weeks.
    When I look at the fighting bots CPU frame time goes to crazy values, like 20ms, while in profiler I can see 10-11ms . When I look the other way, frame time (registered by steamvr) drops to 3-5ms which is what it should be and always was , while profiler still showing same value of 10-11ms (except little change on rendering thread).
    I attached picture below, first part is when I don't look at them, second is when I turn around to them. You can see massive change in real CPU frame times (and fps), but not much in profiler (still oscillating about 10-11ms).
    What I've tried :
    - I disabled all renderers, animators, audio, particle effects, basically all visual items related to bots. no change
    - reverted some scripts from older backups - not much change
    - tested version of my game from march-april , it's ok, while profile reading are similar to current build, real frame times are also (the one reported by steamvr, this huge load is not present)
    - draw calls are low
    - amount of triangles is ok (as I mentioned before I disabled all renderers etc.)
    - physics readings are ok
    - audio readings are ok


    Can't revert the game to march version, because it's released and since then massive amount of features were added, so players will get mad.
    I tested on empty scene with current version, just spawned bots so they fight with each other, issue is still there.
    Just can't see anything different in profiler (times, scripts, GC) comparing to march version (which works fine)
    It's worth to note also that issue happens in build only. Profiling in editor VR game is pain in the b***, but I don't see that massive change when I start to look at these fighting (shooting each other) bots as I see in build.
    I reverted all project settings also to old version, checked all shaders, checked netcode, debugged half of the code...nothing. Did some update for assets I use there, reverted them to older version, removed heaviest features I added since march...still no idea.
    I just can't understand why steamvr graph shows such a big change (which is real change in performance) while profiling not really. I've tried deep profiling, but its overhead is so big, that it's hard to read anything from it that makes sense.
    I'm not asking for solution, I just ask what else I could check, because it ruined my xmas and still have no clue
    Unity 2019.4.40, build in rp

    Thank you in advance and Happy New Year!
     

    Attached Files:

  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,406
    You have toggled of visualizing of the Global Illumination and Other categories in the CPU Usage Chart Legend. I would assume GI is negligible but Other could be were the missing 20ms in the chart are hiding. Tick those black boxes and reactivate them so see it in the chart. Contrary to popular believe, Other is not the same as Editor loop overhead, even if that is usually the biggest contributor in the Editor.

    Further, the Steam VR profiler utilizing native/hardware counters means it knows more precisely what stretches of the frame time are idle times on the CPU. Unity knows when its code is waiting for another thread, which presumably means the main thread is idle, but that assumption is not the same as having a hardware counter that actually confirms that it is idle. This difference in displaying the information is likely why you're seeing lower than 10ms frame times in the steam VR profiler.

    Looking at the timeline view of the profiler might show the differences between these frames more clearly and may hint at what is the issue in those frames. It is also unaffected by the filtering you've applied through the chart and may more clearly show idle times.
     
    DevDunk likes this.