We have a significant chunk (.2ms+) of time being spend in WorldGridMaterial in both the raster queue and the compute queue during Nanite VisBuffer. What causes this and how can I reduce it?
Steps to Reproduce
- Set r.ShowMaterialDrawEvents=1 and r.EmitMeshDrawEvents=1
- Create an empty level
- Add an editor sphere mesh to the level
- Run ProfileGPU
- Look at NanitVisBuffer->SW Rasterize
Hi there,
This is the default raster material for nanite meshes. You are seeing a lot of time here because most of your meshes will end up in the default raster bin (this is the fast path). This is a little confusing, but the engine just uses the default material for nanite rasterization for anything that doesn’t require special handling (programmable raster for things like world position offset, masked materials, etc). This doesn’t mean that it will run the World Grid Material shading graph however (the materials used for shading are still the actual materials of the objects on screen), it is only using this material for default rasterization settings, for the rasterization stage of the pipeline.
If you have any more questions about this, let me know.
Regards,
Lance Chaney
Hello!
Thank you for your answer. That’s pretty much what I’d guessed looking at what geo it was drawing. I’m also guessing the fact that it runs multiple of these draws with the default grid is because it’s doing the different fixed function buckets (i.e. spline, two-sided, skinned, etc)? If so - it would be awesome if the annotations on these draws were more descriptive of what geometry they were processing.
Since Nanite can process multiple meshes, from different objects, in the same raster bin, it’s not really possible to output which meshes are being drawn in the annotation. That’s why you only see the material it’s using listed.
You can however check your raster bins visually using the Raster Bin visualization mode from the view mode dropdown.
[Image Removed]As for the multiple passes, the rasterization stage is typically split into two branches. The HW Rasterize pass is for processing mesh clusters with large on screen triangles, while the SW Rasterize is for processing clusters small on screen triangles (typically for triangles smaller than a few pixels). The MainPass HW/SW Rasterize passes process all the clusters that were visible last frame after frustum culling. The PostPass HW/SW Rasterize passes process the new clusters that have become visible in this frame. This split is so that Nanite can do very accurate cluster culling after the first set of clusters (which are very likely to be visible because they were visible in the last frame), have been rasterized. Note that Unreal outputs a GPU event annotation for each raster bin in under each HW/SW Rasterize event, even if nothing actually ends up in those bins. So some of these will be empty events with zero draw/dispatch calls.
Regards,
Lance Chaney