Low terrain tree FPS but wierdly Low CPU and Low GPU usage?

Working on a large terrain project (8 km^2 ) and getting some very strange benchmarks early on.

I'm getting low < 20 fps but also very low CPU and GPU utilisation (build and in editor)

Digging into the profiler in editor mode and the rendering systems is definitely the slowdown:

Camera Render Taking 67 ms

PerpareSceneCullingParameters taking 17 ms but even in deep profile it looks like none of the sub methods it calls can account for more than 2% of this.

• This seems to be an ongoing issue with Unity and Speedtree (found a lot of other threads from the last few years regarding this issue).
  • 2010 https://forum.unity.com/threads/unity-3-tree-performance.57254/
  • 2012 https://forum.unity.com/threads/trees-slow-down-the-game.160184/
  • 2013 https://forum.unity.com/threads/batching-trees-and-speed-up-rendering.138929/
  • 2013 https://forum.unity.com/threads/using-tree-gameobjects-vs-unitys-built-in-system.183224/
    
  • 2014 https://forum.unity.com/threads/terrain-trees-causing-slow-framerate.231931/
  • 2015 https://forum.unity.com/threads/speed-tree-optimisations.317585/
  • 2015 https://forum.unity.com/threads/speedtree-performance-issues.332494/
    
  • 2019 https://forum.unity.com/threads/speedtree-issues-in-hdrp.738689/
• Could this process benefit for multi-threading seems odd that generating the parameters becomes a performance bottleneck?

Then WaitForJobGroupID which is called in two places seems to take about > 3 ms each, which seems excessive.

Note: Using the Standard Rendering Pipeline.

Wondering why this has not been addressed especially with super powered consoles around the corner and gamers expecting more open world games combined with Unities drive for performance by default?

 

Just a reminder that Unity was able to make this demo...

Then why can't we make large tree filled terrains easily out of the box, what is the point of spending all that money making amazing demos when the basic engine technology does not get improved?

PS Judging from the blog post it seems that dedicated high end mesh rendering and shader technology was used for the demo and not the default terrain and speed tree technology.

 

Well, SpeedTree...

<rant>
We made a compute shader to
- Cull trees
- Compute LOD's
Then we draw everything with DrawMeshInstancedIndirect calls.

Guess what?

We are still CPU bottlenecked, because DrawMeshInstancedIndirect is so much slower in Unity than other draw calls that it compensates for all the CPU optimization we did by moving stuff to the GPU...

It spends CPU time
- When you submit the call
- When it processes the command buffer (on the Main thread!)
- When it processes the command buffer again (on the Render thread - graphics jobs do not apply here)

Graphics Jobs, SRP batching none of the optimizations apply when you use DrawMeshInstancedIndirect.

So good luck with SpeedTree vs Unity
</rant>

 

I was amazed at how long this has been an issue that has not been resolved, especially with the new DOTS/Multi-threading/Burst 'performance by default' approach taking over.

 

Raised it as an issue on the DOTS side of the forum https://forum.unity.com/threads/could-dots-fix-the-unity-terrain-tree-performance-problem.931554/

 

Are you using billboards + DrawMeshInstancedIndirect (just let GPUInstancer do it for you)?

You shouldn't have an issue getting something like 10k trees running fine. Overdraw will be the unsolvable issue at higher numbers, depending on the tree shape.