delicate moss
This is a 2021 lts il2cpp client running on our min specs Intel I5-7200U 2.50MHZ (2 cores, 4 logical processors). The client is profiled remotely by an editor runs on my work machine. I also built it with 2022.2 as well to compare and there was little difference.
In the scene there is just a flat terrain, a couple of hundreds draw calls, a stacked camera for the UI and the bloom effect. No shadows are enabled.
frame debugger view:
in my (humble) opinion, 10 ms for this is absurd
Thoughts on why a very simple URP scene is using so much CPU time
I do think the terrain is one of the biggest offender and it doesn't make much sense, so I am going to switch to mesh terrain rendering for testing
abstract quartz
Thank you for sharing that @delicate moss , I'll share it with the URP team and we can take a look into it!
delicate moss
by the way: I am starting to wonder if remotely profile over wifi may cause issues, just asking in case we find out that's a problem
I have also no clue if something like this is affecting the profiling:
sweet harbor
@delicate moss I think there are some heavy counters that require lots of unnecessary computations (Used Buffers Count and Used Buffers Bytes). You should see which exactly counters those are by clicking the small samples within flush counters sample. Could you please try disabling Rendering module in profiler window. That should help to remove the stall. Also I believe we have a fix for the issue in flight as https://issuetracker.unity3d.com/issues/release-player-is-consuming-initializationprofilerstartframeregistrator-in-non-development-mode
delicate moss
out of curiosity why the bug description states to copy the superluminal dll?
I profile with superluminal I don't need to copy anything
oh I see
found in the documentation interesting
I will try your suggestion next time I profile, but I doubt is the real problem
the game frame rate doesn't change in release. Unless what the bug report is saying causes the problem in release too?
that would be upsetting