SRP Batching - Performance characteristics (case 1209865)

[Ng0ns]

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

[arnaud-carre]

Hi!

We’re interested to study this un-common case. Dividing FPS by two when enabling batcher is not expected at all, so we may have a corner case.
First, global FPS is not a good metrics for SPR batcher codepath. ( I mean, there is an issue when the framerate drop by two, but the cause may be another part of the engine we should look at). To be sure of SRP Batcher ON/OFF impact, you should use SRPBatcherBenchmark/Assets/Scripts/SRPBatcherProfiler.cs at master · Unity-Technologies/SRPBatcherBenchmark · GitHub

Could you post two screenshots of your test 3, with SRPBatcherProfiler.cs enable? ( when enable you can toggle batcher ON/OFF with F9 key)

Btw if it’s not an issue for you you could also post your test3 repro project so we could have a look.

[Ng0ns]

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 GitHub - Scumworks/SRPBatcherTest

-Cheers

[arnaud-carre]

ok so this is a use case we know batcher could be slightly slower ( 10% of CPU rendering time, not 10% of global frame time). This is exactly the case of test3: all objects are “static batched”. ( so you go from 1.49ms to 1.62ms (about 10%))
We may improve the SRP Batcher for this use case in future (where almost all the scene is made of static batched geometry)
( as a test, if you disable static batching, you will see huge benefit of SRP Batcher )

Anyway I still don’t get where you go from 60 to 36fps. Is it a different scene?

[hippocoder]

@Ng0ns

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.

[Ng0ns]

@arnaud-carre

ok so this is a use case we know batcher could be slightly slower ( 10% of CPU rendering time, not 10% of global frame time). This is exactly the case of test3: all objects are “static batched”. ( so you go from 1.49ms to 1.62ms (about 10%))
We may improve the SRP Batcher for this use case in future (where almost all the scene is made of static batched geometry)
( as a test, if you disable static batching, you will see huge benefit of SRP Batcher )

Anyway I still don’t get where you go from 60 to 36fps. Is it a different scene?

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.

[hippocoder]

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

[Ng0ns]

@hippocoder

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.

@hippocoder

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

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

[Ng0ns]

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.

[BattleAngelAlita]

@arnaud-carre

this is a use case we know batcher could be slightly slower

What exactly cause slowdown? Multi materials?

[arnaud-carre]

using FPS is often tricky to really measure what happen. Better look at the absolute time in ms. So the large fps drop only occurs on mobile right? Do you have screenshot of SRPBatcherProfiler.cs running on mobile? ( so I can get better idea of the slowdown regarding the rendering code path).

[Ng0ns]

@BattleAngelAlita

What exactly cause slowdown? Multi materials?

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

@arnaud-carre

using FPS is often tricky to really measure what happen. Better look at the absolute time in ms. So the large fps drop only occurs on mobile right? Do you have screenshot of SRPBatcherProfiler.cs running on mobile? ( so I can get better idea of the slowdown regarding the rendering code path).

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.

[arnaud-carre]

ok I know what happen. It’s not directly related to having multiple material per mesh. It’s more like SRP Batcher corner case with plenty of static geometry has 10% slowdown right now. This slowdown comes from binding and uploading some “builtin” buffers, that could be avoided in static geometry context.
The main issue is that un-necessary binding codepath seems to be extremely slow on mobile ( compared to 10% corner case on desktop)
Please fill a bug. Put something with “SRP Batcher static batching huge slow down on mobile” in the title. I will work on a fix. Even for corner case, such slow down on mobile should be fixed.

[Ng0ns]

@arnaud-carre

ok I know what happen. It’s not directly related to having multiple material per mesh. It’s more like SRP Batcher corner case with plenty of static geometry has 10% slowdown right now. This slowdown comes from binding and uploading some “builtin” buffers, that could be avoided in static geometry context.
The main issue is that un-necessary binding codepath seems to be extremely slow on mobile ( compared to 10% corner case on desktop)
Please fill a bug. Put something with “SRP Batcher static batching huge slow down on mobile” in the title. I will work on a fix. Even for corner case, such slow down on mobile should be fixed.

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.

[DavidSWu]

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.

[hippocoder]

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.

[GunLengend]

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

[hippocoder]

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?

[buFFalo94]

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

Performance going downhill with latest versions of Unity, Post Processing and SRP

@Devil_Inside didn’t have time to test 2019.3 or 2020.1 But after more test in 2019.2 I have come to conclusion that LWRP perform well and here is some tips Don’t use static batching SRP Batcher help sooooo much for scenes with many draw calls, I’ve been able to run some scenes with more than 1M, more than 2000 draw calls and shadow(only directional light) at 15-20fps@720P Vulkan is buggy and unstable can’t rely on it

In conclusion SRP Batcher works great

[GunLengend]

@hippocoder

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 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