Task Graph scheduler behavior during concurrent async loading in UE5.x

Answer to the Core Question

When the Task Graph worker pool is fully saturated, UE5 does not pre‑empt a running worker. The scheduler orders ready tasks by the following hierarchy:

• Task readiness – a task can only be scheduled once all its dependencies are finished.
• Named‑thread/priority class – each task carries a priority flag and a target thread (Game, Render, Audio, etc.). The scheduler prefers tasks whose target thread is free and whose priority class is higher.
• Dependency completion – a high‑priority task that depends on a lower‑priority task will still wait until that dependency finishes.

Because U‑registration (the finalization that runs on the Game Thread) is serialized with the Game Thread, a saturated worker pool can cause high‑priority tasks to wait behind long lower‑priority tasks or behind an unfinished prerequisite. UE5 does not expose a dedicated CVar to “unstarve” U‑registration; the documented mitigation is to control load concurrency, keep prerequisites shallow, and avoid blocking tasks on named threads.

Likely Explanation of the Observed Jitter

• Concurrent async loading spawns many worker tasks for I/O, decompression, and object construction.
• When the worker pool is saturated, some of those tasks finish late, leaving the Game Thread idle for a longer period while it waits for U‑registration to complete.
• The spike in DeltaTime is therefore a symptom of the Game Thread being blocked by finalization, not a direct result of worker starvation.

Confirmed Facts

• UE5’s Task Graph scheduler does not pre‑empt running workers.
• Priority is encoded on the task and is respected only when the target thread is free.
• There is no official CVar that forces U‑registration to run ahead of other tasks.
• The behavior and default values differ between UE5.x minor releases; verify against the exact engine build you ship.

Steps to Verify and Mitigate in Your Project

1. Reproduce the spike in a controlled map. Trigger a high‑priority gameplay load while several background async loads are in flight.
2. Capture a trace with Unreal Insights. Open UnrealInsights.exe, enable the TaskGraph and GameThread channels, and record a few seconds of gameplay.
3. Inspect the trace: locate the high‑priority task’s Begin and End timestamps. Check if it is waiting for a dependency or for the Game Thread to become free.
4. Profile the Game Thread finalization. In the trace, look for the UObject::PostLoad and UObject::Register phases. If these span a large portion of the frame, the jitter originates here.
5. Throttle async loads. Reduce the number of concurrent async loads (e.g., via AsyncLoad::SetMaxConcurrentLoads) and re‑measure. If the spike disappears, the issue is load‑concurrency‑driven.
6. Move non‑critical finalization off the critical frame. For assets that can be finalized later, set bAsyncLoad or use LoadSynchronous only when necessary.
7. Verify engine version. Open Engine/Source/Runtime/TaskGraph/Public/TaskGraphInterface.h to confirm the priority enum and any CVar defaults for your build.

Missing Diagnostic Detail

To refine the recommendation, please confirm: Is the stall occurring during async I/O/decompression, or during the Game Thread’s U‑registration/post‑load phase? This determines whether you should throttle I/O or restructure finalization.

Practical Takeaway

• Control the number of concurrent async loads.
• Keep dependency chains short; avoid deep prerequisite trees.
• Avoid assigning critical gameplay tasks to named threads that may be blocked by U‑registration.
• Use Unreal Insights to confirm where the frame budget is consumed.