SRP Batching - Performance characteristics (case 1209865)

Hi people

So, on an off I test the waters to see if it would be worth to switch to the, now "universal" render pipeline, on my android project in terms of performance.

At the moment I rely on large texture atlases (single material) to keep drawcalls low, so I was hoping the SRP batcher would allow more materials without penalties.

• Test scene contains 1024 houses (32x32 grid), static with baked lightmaps.
• Each mesh/house is a single mesh and sums 697 verts, 917tris.

Testing was done on my HTC10, which supports ES3.2 and according to systeminfo.graphicsDeviceVersion was running that. All materials use "Simple lit" shader.

Test 1
Single material, reused on all meshes. 2048 diffuse texture assigned (see image 01 for ref.).

60+ fps

Test 2
Each house use a single material but vary between 16 different ones, each assigned a 512 diffuse texture (see image 02 for ref.).

In this scene I reached 60+ fps with or without SRP batcher enabled. I know this is capped but other tests done shown no benefit having SRP batcher on or off. Looking at the frame debugger, its clearly doing its job, but theres no performance difference.

Test 3
Each house use 4 different materials (submesh) with 4 different variants within scene (so again 16 different materials in all), each material use a 512 diffuse texture like before (see image 03 for ref.).

This is where things get interesting.

SRP batching OFF
60+ fps

SRP batching ON
36 fps!

It seems assigning multiple materials to the same mesh (different parts of cause) has a huge impact on performance when SRP batching is enabled.

I know 16 different materials within a scene isn't a lot, but I'm surprised to see almost nothing gained when toggling SRP batching on an off. I'm also really sad it see it tank when using submesh materials, especially having thought it the other way around.

Am I just doing it wrong?

Cheers

 

Hey Arnaud, thanks for the reply

Applied the profiler script, screenshots attached. Couldn't toggle with f9 (just refreshed display), so I just did so in the URP asset.

Numbers differ between editor mode and building to the phone tho. In "All object" I'm getting 55 applyshader calls in editor, but only 16 on phone with SRPB off, and 4 versus 2 with SRPB on.

I've put the project on github https://github.com/Scumworks/SRPBatcherTest

-Cheers

 

If it's possible to send this scene as a bug report and drop the case number in this thread it's easier for staff to take a look at.

 

The 60 to 36 is on the phone (android project on my HTC10), screenshots are editor. I ran test3 on the phone with the SRPBatcherProfiler.cs script, and it show the same.

Edit - Sorry, I realize its easy to overlook in the garble of text that I'm talking about a mobile project.

 

Unity needs a case number and your test project to further advise really.

 

Sure, np. I'll make a bug report.

 

So I did a little more testing. When disabling static batching on the meshes, toggling SRP batcher off yield roughly a 4 fps increase to around 40, which seems to co aside with the 10% overhead which was mentioned (on test3).

I also converted back to the build-in renderer to see what kind of performance it has. Much like URP the first two test doesn't differ much, it does however show the same issues when dealing with "test 3" and having multiple materials assigned to the same mesh (also halves fps).

So I guess the question is why fps increases when disabling SRP batcher to the extend that it does.

 

What exactly cause slowdown? Multi materials?

 

Yes, multiple materials assigned to the same mesh (e.g. like different sides of a cube etc.).

Seems like its mobile only, though I haven't done any tests.

Here's some screenshots taking on the phone. I've build both as a standard and development, no difference.

 

I filed a report yesterday under the name "SRP Batcher - Performance issue with multiple subobject materials on android". According to fogbugz it should have case number 1209865. Thanks a lot for looking into this

- Cheers.

 

So is it recommended not to use static batching with the SRP batcher for current production builds?
We have disabled static batching anyway on mobile because it can use up a lot of memory and the srp batcher seemed to solve the problem "about as well" in terms of performance.

 

Well, static batching can be heavy and a bit sucky, it's very much one of those features that's always been sort of try it and see rather than guaranteed improvement. Personally I have zero use for it and never have since it's always been slower for me. Probably because I use generally good practises + instancing etc... it just becomes pure overhead in a modern pipeline IMO.

If it looks like the frame time is way too long it could well be a bug though.

 

Facing the same issue on Android with my project. Huge performance decrease.

 

Yeah if you're using static batching wrong (like for lots of small things you want to combine that are the same) - it will be really quite a bit slower. Don't use static batching to lazy-combine. It's not for that... use instancing for those instead.

Also don't forget, each separate element in a static batch is also checked uniquely for culling so those overheads will always exist unless things are properly merged beforehand.

Can you see where your time goes with profiler?

 

Static batching in huge scene consume too much memory especially when targeting mobile platform, the overhead is unacceptable. I also did some test and posted some findings here
https://forum.unity.com/threads/per...-post-processing-and-srp.786944/#post-5245754
In conclusion SRP Batcher works great

 

Can you add more clarify here, we didn't use static batching but the issue still exists, FPS now up to 40 but built-in render make it 60. Also, enable SRP batcher cause negative "saved by batching" on Editor. See the attached picture, I'm using URP 7.2.1 and Unity 2019.3.0f6

 

The stats window is unreliable still, and Unity will take a pass over that when things have settled so rely on profiler and of course the frame debugger.

Typically though it'll be shaders or post effects ruining your mobile perf first. In this case though I see alarmingly high CPU usage.

The screenshot you posted isn't helping you, please master the profiler, and profile the android device, not the editor.

 

First, thank for your time and consideration of the topic. Second, let me takes more deep test and give some screenshots for an easy understanding of the issue.

 

Just so i'm clear on thi SRP Batcher with materials. Does SRP ignore the material instancing option ? I'm guessing if the material can be batched through SRP it ignores the material instancing but can someone confirm this please.

 

Material instancing is replaced by the SRP batcher when it's active and material instancing has no effect. It's just dormant UI.

SRP batcher batches by shader, not material anyway.

 

Can someone please explain this further? I don't understand how having lots of static geometry, few materials and 1 shader variant can be a corner case. Which case would the SRP Batches be well suited then?

Can you provide the bug link?

 

I gave the Github project a run in an iPad mini 2 and it went from 39fps (17.91ms CPU Rendering time) with SPR Batcher on to 42fps (19.36ms CPU Rendering time) with SPR Batcher off.
Using Unity 2019.3.13.

 

Maybe the srp batcher should just ignore static geometry given that it's better handled without it? If it's somehow possible of course