Less FPS with SRP batcher on (Android, Unity 2020.3.12f1)

Hi everyone!

I am currently developing a game for Android and iOS and I was under the assumption that the SRP batcher would improve the performance but this is not what I see.

On my device when I compare the FPS with or without the SRP batcher I get better results without it (between +3 and +8 FPS for a target of 60 FPS*). When I use the frame debugger (on the device still) I see that the SRP batcher is working very well because I see more than 10 to 40 times less draw calls when it is on, but this doesn't translate to better performances.

Is this somehow expected or is there something strange going on?

*my device is not very powerful, the game runs smooth at 60 FPS on a Pixel 1 for instance.

 

You seem to have a slight misunderstanding
@bgolus said it well, so quoting him:

"The frame debugger isn't showing draw calls. It's showing internal renderer thread events. Each event may produce multiple draw calls.

Also the SRP Batcher isn't making drawing multiple objects use one "draw call", instead it makes those draw calls much cheaper. This was true of static batching too btw. If you have 4 objects that are staticly batched, it shows as one event in the frame debugger, but it's still 4 draw calls if you use RenderDoc (on PC) or XCode.

One thing to understand is draw calls themselves are not necessarily expensive. Changing the rendering settings (shader or shader variant, mesh, blend mode, textures in use, material properties, object position, etc.) is the expensive part. The idea behind the SRP Batcher is to try to reduce the settings change cost."

As to why it's worse, I'm not quite sure. It might have diminishing returns on mobile. Just a guess.

 

I suspect that you might be more GPU-bound rather than CPU. You might have save on the "switching rendering states" part using SRP batcher, but if your Shaders are complex, you might have killed performance as the renderer might be waiting for the graphics device to finish rendering the frame to issue the next batch of instructions.

 

The odd part about using complex Shaders, is that by having the expensive "switch states" in between rendering, is that it allows the device to finish processing the frame while the CPU is preparing the data for the next state, thus resulting in a much "smoother" rendering sequence flow.

 

Thanks a lot for your replies, I certainly had some misconceptions about the frame debugger.

I try to optimize my game to the maximum so my shaders are quite simple. I use shader graph and the most complex + used shader is an unlit shader with a custom function to handle one directional light. It also has a couple boolean keywords. Also I should mention that this shader is used by around 20 materials with different parameters, all used in the scene I use to compare FPS.

The device on which I try to stay as close as I can to 60 FPS is a Xiaomi A2 Lite so I definitely think it is GPU bound (not much happening in the scene I use to compare the FPS, and overall my game doesn't use that much CPU as it is a pretty simple puzzle game).