I’ve been looking into some recurring CPU frametime spikes in Fortnite. I synced a CapframeX capture with the game log and noticed a lot of my >10 ms frames seem to line up with level streaming / actor registration work.
One thing that stood out to me is that in the logs is that some of the relevant CVars use fixed millisecond budgets, for example:
s.LevelStreamingActorsUpdateTimeLimit = 5Athena.NormalStreamingAsyncLoadingTimeLimit = 6s.PriorityLevelStreamingActorsUpdateExtraTime = 10s.PriorityAsyncLoadingExtraTime = 40
I know these are budgets/limits and not necessarily time that gets used every frame, but I’m wondering if fixed values like this make as much sense at very high FPS.
At 60 FPS you have 16.7 ms per frame, but at 400 FPS you only have 2.5 ms. So even a 5 ms streaming budget is already 2 full frames worth of time relative to the normal frametime.
In my captures the game can be sitting around 2–3 ms per frame, then I’ll get a 10–20+ ms CPU frame around streaming/actor work, then immediately go back to ~2–3 ms.
It made me wonder if some of these budgets could be based more on current frametime/headroom rather than being fixed values. For example, if the game is targeting 400 FPS and the current frame is already close to 2.5 ms, do less streaming work that frame and spread it out more. If there’s plenty of headroom, allow more.
I’ve also seen WildEstateRendering show up around some of these streaming events. It appears to be a Fortnite-specific system that processes actors when streamed levels are added. Does that work adhere to the usual level-streaming time budgets, or can it do additional work outside of them?
I’d like to A/B test something simple like changing s.LevelStreamingActorsUpdateTimeLimit from 5 ms to 1–2 ms and comparing the frametime spikes against any increase in pop-in / streaming delay, but these CVars seem to be locked or ignored in Fortnite’s shipping build.
Thanks for any insight.