Summary
In a Development packaged build (UE 5.8.3 Launcher, Win64, D3D12 / SM6), process memory grows slowly over long runs. The main growing LLM tag is SceneRender: about 8.5 → 108 MiB over a 4-hour run, still growing in the last hour (process memory about +25 MiB/hour).
The growth stops when either hardware ray tracing (r.RayTracing=False at startup) or Lumen diffuse GI (r.Lumen.DiffuseIndirect.Allow=0) is disabled. Disabling only r.LumenScene.Radiosity.HardwareRayTracing does not help. UObject counts, handle counts and the LLM Graphics tag stay flat.
This looks similar to UE-268241 (about 10 MB/hour, avoided by r.RayTracing=False, marked fixed in 5.6), but we see it on 5.8.3, so it may be a regression or a different issue.
What Type of Bug are you experiencing?
Rendering (Graphics / Niagara)
Steps to Reproduce
Seen in our own packaged app; not yet reduced to a blank project.
- UE 5.8.3 (Launcher), Windows, D3D12 / SM6. Relevant renderer settings (a subset, not yet reduced to a minimal set): r.DynamicGlobalIlluminationMethod=1, r.ReflectionMethod=1, r.Lumen.HardwareRayTracing=True, r.Lumen.HardwareRayTracing.LightingMode=0, r.Lumen.TraceMeshSDFs=0, r.Lumen.ScreenTracingSource=0, r.GenerateMeshDistanceFields=True, r.AllowStaticLighting=False, r.RayTracing=True, r.RayTracing.Shadows=False, r.Shadow.Virtual.Enable=1, r.VirtualTextures=True, r.GBufferFormat=1, r.PathTracing=True. Log at startup: ‘Ray tracing is enabled (dynamic). Reason: r.RayTracing=1 and r.RayTracing.EnableOnDemand=1.’
- Scene: one animated skinned mesh (a generated test VRM, loaded at runtime with the VRM4U plugin), fixed camera, dynamic light, Lumen GI and reflections.
- Package a Development build. Run it with -llm -llmcsv and LLM.LLMWriteInterval 60.
- Let it run for 60 minutes and compare the SceneRender column in the LLM CSV.
- Run the same exe with -ini:Engine:[/Script/Engine.RendererSettings]:r.RayTracing=False (the log confirms ‘Ray tracing is disabled … (r.RayTracing=0)’) and compare.
Expected Result
After warmup, LLM SceneRender and process memory level off instead of growing for as long as the app runs.
Observed Result
With ray tracing on, SceneRender keeps growing. With ray tracing off, it stays flat.
- Side by side, 60 minutes (two instances of the same exe started together), SceneRender MiB at 10 / 20 / 30 / 45 / 60 min:
- normal: 7.8 / 10.0 / 14.9 / 18.8 / 24.2
- r.RayTracing=False: 4.2 / 4.2 / 4.3 / 4.3 / 4.3
- 4-hour run (normal): SceneRender 8.5 → 108 MiB, still growing in the last hour.
- r.RayTracing=False as a single run: flat at about 4.3-4.5 MiB in 3 separate runs (60, 60 and 20 min).
- r.Lumen.DiffuseIndirect.Allow=0 (ray tracing still on): flat in one single run and two side-by-side runs.
- Only r.LumenScene.Radiosity.HardwareRayTracing=0: grew the same as normal when run side by side (+4.16 vs +3.85 MiB per 100k game frames over 60 min).
- UObject counts don’t grow, handles are stable, and the LLM Graphics tag is flat.
Affects Versions
5.8
Platform(s)
Windows
Additional Notes
- Hardware: RTX 3070 Laptop 8 GB, NVIDIA driver 581.80, Windows 10.0.26200.
- Our app also contains a custom SceneViewExtension / RDG capture pass and the VRM4U plugin. We have not yet ruled these out in a blank project, and no allocation call stacks have been captured yet.
- The growth rate varies between runs: the normal build has a ‘fast’ and a ‘slow’ state with identical CVars, FPS and GPU utilization. So we only trust differences seen side by side.
- Related: UE-268241 (marked fixed in 5.6, commit 42413393), and a community report of similar LLM growth with HWRT on 5.3-5.6: RHIMisc, EngineMisc, SceneRender Virtual Memory Leak
Questions:
- Is this a known issue or a regression after UE-268241 in 5.7 / 5.8?
- Which trace would you like us to capture, e.g. Memory Insights with call stacks on the SceneRender tag?
- Is there a narrower CVar than r.RayTracing=False or r.Lumen.DiffuseIndirect.Allow=0 that avoids the growth?
We can share anonymized logs and the per-minute LLM CSVs.