Search Unity

Universal Render Pipeline SRP batching act strange

Discussion in 'Editor & General Support' started by MKFusion, Oct 30, 2020.

  1. MKFusion

    MKFusion

    Joined:
    Jan 12, 2017
    Posts:
    24
    Hi,

    in my project, which is intended for mobile I have many grass like objects, so I try to reduce batches.
    Problem occurs when I use SRP batching setting as it is. In that case I see a large negative number in "saved by batching" section, for example batches 1568, saved by batching -1560 and game lags on android tablet obviously.

    If I disable SRP batching, and enable GPU instancing on material (URP standard lit), then I do get reduced draw calls and around 100 batches instead of 1500, as seen in stats on the attached images.

    One thing I noticed in Frame profiler is error: "SRP: First call from ScriptableRenderLoopJob" on that part that is rendering grass objects. Did anyone have such error and how to solve it ?

    One way would of course be, to continue with disabled SRP batching, but I really would not like to, if there is a way to solve it.
     

    Attached Files:

  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,461
    Hi

    Pre 2020.2, SRP had no way to correctly report batch counts to the stats view or profiler, so please ignore those numbers on these versions. Btw, at the bottom of the Frame Debugger manual page is a list of some more tools to analyze graphics performance, besides the Unity Profiler and Frame Debugger.

    This is displayed on a Batch of 500 draw calls. That looks batched to me, unless you have 1500 of these. The note there just indicates that it couldn't be batched together with items higher in the left hand list of the Frame Debugger, not that it couldn't be batched at all. In this case, it was just the first thing in the SRP batcher that got batched in a job meant to batch these together.

    98 batches just is still quite a few and possibly too much for an android tablet. Plus the issue might be fill rate (i.e. GPU bound and high Shader complexity) instead of CPU load to render and prepare work for the GPU or the Render Thread. Try using the Profiler and check out the Render Thread. The CPU Profiler Module's manual page lists some common sample names that might help you determine if you are CPU, GPU or vSync bound.
     
  3. MKFusion

    MKFusion

    Joined:
    Jan 12, 2017
    Posts:
    24
    Thank you for explanation,

    98 is still much yes, but it is a worst case scenario in this case and works on average tablet. I would rule out shader complexity as it is simple lit URP for a test.

    Otherwise, yes, test above was done with around 1500 objects and with SRP batching a "no go", and without it it works even on a tablet. As said before that was an extreme case.

    As of Render Thread, apart from Render Camera (average 12ms), the most time takes "Gfx.WaitForGfxCommandsFromMainThread"(average 3ms). Without SRP batching those same numbers are lower.
     
  4. MKFusion

    MKFusion

    Joined:
    Jan 12, 2017
    Posts:
    24
    In percentage it is like this. With SRP batcher 12% takes SRPbatcher.flush
    Without 3% takes Batchrenderer.flush
     
  5. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,461
    Gfx.WaitForGfxCommandsFromMainThread takes 0 processing power from the CPU. During those times the Render Thread is just waiting for more work items from the main thread, as the name indicates. This ample taking longer therefore isn't necessarily a bad thing. it can indicate that the work load isn't well balanced and timed between these threads but you need to look at this rom the timeline view. from the start of your rendering work on the main thread,to it finishing on the Render thread, does it take longer or shorter to finish sending everything over to the GPU? How long does the Render Thread then have to wait on the GPU (Gfx.WatForPresent)?