[Gpu hung] RenderVirtualShadowMaps(Nanite) - NodeAndClusterCull

Development Rendering
, ,
1

All the crash file is below.

2

重现步骤
Hi, we have met gpu hung in our development game. ​The nv-gpudump shows the crash is related to PageRectBoundsBuffer memory access invalid. It happens on nvidia 4060 when loading the level.[Image Removed]

3

Hello,

We are seeing similar GPU crashes in this area but don’t have a known fix yet. For now we’re tracking the work on this issue here: Unreal Engine Issues and Bug Tracker (UE\-230827) The crash is in a different function and pass, however it appears to have similar characteristics.

4

Thanks, Alex. I have some new info. If i turned off async compute transient aliasing(r.RDG.AsyncComputeTransientAliasing

0 ), the crash seems not happened any more.

5

By any chance do you have a way to repro this issue that you can share with us?

6

Hello, I just found this thread looking for more info on this crash, and I may have a consistent repro in the editor with the City Sample project:

  • Create a new project from the City Sample fab with UE 5.5.4
  • Open Small_City_LVL
  • Load a world partition area and save so that it loads that area when opening the map
  • Switch to software Lumen in the project settings (disable raytracing)
  • Restart and open Small_City_LVL while shaders are still compiling (using -noshaderddc if necessary)
  • At this point, I get the NodeAndClusterCull GPU crash while the level loads 100% of the time.

GPU info:

[2025.08.30-17.38.22:903][  0]LogD3D12RHI: Found D3D12 adapter 0: NVIDIA GeForce RTX 4080 (VendorId: 10de, DeviceId: 2704, SubSysId: 13bd196e, Revision: 00a1
[2025.08.30-17.38.22:903][  0]LogD3D12RHI:   Max supported Feature Level 12_2, shader model 6.7, binding tier 3, wave ops supported, atomic64 supported
[2025.08.30-17.38.22:903][  0]LogD3D12RHI:   Adapter has 16050MB of dedicated video memory, 0MB of dedicated system memory, and 32651MB of shared system memory, 2 output[s]
[2025.08.30-17.38.22:903][  0]LogD3D12RHI:   Driver Version: 566.03 (internal:32.0.15.6603, unified:566.03)
[2025.08.30-17.38.22:903][  0]LogD3D12RHI:      Driver Date: 10-15-2024
7

Sorry, I am unable to consistently reproduce this issue.

8

[Content removed] does the crash you’re experiencing happen in 5.6 with those steps?

9

Ah, sorry I misread this ticket, I’ve only tested this for 5.5.4

10

Hi! We’re running into what appears to be the exact same crash. Setup in our case:

  • UE 5.8.4, D3D12, crash happens only to NVIDIA GPUs, seen on drivers 610 and (latest at the time) 621, so far editor-only.
  • Repro: open a large level with several streaming sublevels, on the affected machines (one or two in the studio) this produces a DXGI_ERROR_DEVICE_HUNG every time, on the first few frames after loading.

The breadcrumbs show this happening at Nanite::DrawGeometry > NoOcclusionPass > NodeAndClusterCull. We got good afertmath logs and figured the crash is coming from GetCacheTransitioned on VirtualShadowMapPageCacheCommon.ush, specifically this line:

	return (Scene.VSMCache.CacheInstanceAsDynamic[ViewWordOffset + WordOffset] & WordMask) != 0;

Judging by the logs, we think the SRV descriptor on CacheInstanceAsDynamic is holding a bad base address.

Lumen’s ScreenProbeGather is always running on the async-compute queue at the moment of the crash. We found that Lumen’s tracing passes binds the Scene uniform buffer (GetLumenCardTracingParameters), and so we suspect that the crash has to do with the fact that the buffer owning VSMCache.CacheInstanceAsDynamic is referenced by both queues (graphics and async-compute)

To confirm that async compute was involved, we tried the following:

  • r.RDG.TransientAllocator=0, crashes. Same line.
  • r.RHICmd.ParallelTranslate.Enable=0, no crash
  • r.RDG.AsyncCompute=0, no crash

And then:

  • r.Lumen.AsyncCompute=0, no crash

Our current suspicion is that, because after a level load this buffer and its SRV are freshly created, something about that cross-queue use under parallel translation seems to be leaving a bad descriptor.

We hope this helps! To work around the problem we’re disabling async compute on the affected people’s machines in the meantime. We still have a couple of people with 100% repro, so let me know if you want to try any CVars to narrow things further!