We are seeing in our large open world that Nanite spends considerable cpu time. In the order of 1.5->2ms all cores, preparing dispatches for every material instance loaded.
This happens regardless of what’s on screen; we can be looking into the sky, with the gpu doing very little, and no actors visible, yet we still pay this fixed cost on cpu.
[Image Removed]
This is NaniteBasePass, ShadeGBufferCS work. going parallel on all threads for what seems to be every material instance in the scene.
I can see why this happens, cpu doesn’t have access to visibility buffer, and a despatch may need sent to the gpu for each material that may be visible.
Nanite handles this fine on the gpu side, when I’m looking into the sky, GPUtime is a non issue. But we need these cpu cycles back for other task work.
I wondering if some very high level broadphase culling could help, and if nanite already does this, and we’ve done something wrong to break it?
In this capture I have disabled lumen and VSM, so the only ‘View’ should be the main player view.
RHI Submission time is also creeping up, and I wonder if this is ballooning with all the empty dispatches
[Image Removed]
We have a very large number of material instances,
These all stem from landscape. Every Landscape component has 1 or many? “LandscapeMaterialInstanceConstant_###” on it.
For our further out Landscape where use hlods (with a few different grids for different object categories), we have one MI for each of those.<br>
Q: how many MI’s does epic tend to see or expect in a typical shipping scene?
[Image Removed]