Performance problem after upgrade to 2020.3.10f1 LTS

Hi all,

I have been working on my first game independently for a couple of years and chose to stick to the LTS releases in the hope of minimizing the number of bugs and issues I might encounter.

Until recently I had been using 2019.4.14f1 and decided it was time to update to 2020.3.10f1 but after doing so I noticed a fairly big reduction in frame rate and an increase in frame time:

2019: 165FPS (6ms)
2020: 88FPS (11ms)

After doing some reading I discovered that some things have changed in the way these stats are measured and so dived into the profiler to take a more detailed look.

2019:




2020:




Test scene:


As you can see in the screenshots it seems as though the tri count and vert count has increased, along with draw calls, and WaitForPresentOnGfxThread is taking nearly twice as long despite no changes to the test scene or any implementation details. I'm not yet GPU bound, but I fear that by the time I am done adding more content further down the line I will be.

Some details on the project:

* Aiming to target PC / Mac
* Standard render pipeline and standard shader
* Enabled GPU instancing on all materials in scene
* Using deferred rendering for real time lighting
* Single directional light and spot lights for street lights
* Shadow casting turned off where not necessary
* Using single texture atlas
* No baked lighting as the scene is procedurally generated
* Profiling performed on a fairly old test rig with a GTX 550 Ti

Loosing so much just to and LTS upgrade seems insane, so I could use a little guidance on what might be going on here.

I am considering upgrading the test rig to a GTX 1060 based on the Steam hardware survey indicating this is currently the most common GPU in use, but until now I was pleased to be able to offer good performance to those using old hardware.

I should also add that I am considering a future version upgrade to take advantage of some new features such as Shader Graph once URP has support for deferred rendering.

Any input at all would be much appreciated.

 

Thanks for taking the time to read and reply to my post.

I followed your advice and created two builds windowed at 1024x768 with vsync disabled and an on screen FPS counter. Looks to me like both versions perform very similarly so I guess I can stop worrying.

I measured about 250FPS in both instances, perhaps a slightly lower average in 2020 but certainly nothing to be concerned over, so thank you very much for the guidance!

Can we conclude here that its just the editor overhead in 2020 vs 2019 which is much higher then?

I still notice an increase in the number of tris and verts being drawn in 2020 vs 2019 which I don't really understand.

Screenshots for comparisons sake:

2019:



2020:

 

I've repeated the profiling tests today at a more realistic target resolution of 1920 x 1080 and it seems as though the performance measurements between versions begin to diverge as the hardware get closer to its performance limits. At this resolution the frame rate drops from about 110 FPS in 2019 to 95 FPS in 2020.

Perhaps shedding some light on the anomalous tri and vert count differences will reveal the reasons for this, so I'll go ahead and raise a bug as you suggest.

Before I do that though, I also notice that the profiler rendering stats differ in the number of shadow casters with 2019 reporting 0 casters (which seems wrong) and 2020 reporting 236, so could the differences in geometry be related to lighting?

Screenshots for reference...

2019:




2020:

 

Noticed that 2020.3.11f1 was released a few days ago so figured I should test that too just in case, same issue though.

I also note that the FPS drops from around 110 to 95 indicating about 13% reduction in performance, and that the increase in verts from 486.4k to 553.8k is about a 12% increase. Seems an obvious indicator that the engine is just asking the GPU to draw more than previously for some reason.

 

I really wouldn't rely on the stats window in Unity and maybe not even those in the profiler as in various versions they have been incorrect and later fixed. So it could be that there is no real difference between the amount being rendered at all or something has changed maybe a new player setting has adversely affected your project leading to greater rendering.

My suggestion then is the first step to take is to get accurate information between your two builds on exactly what is happening per frame and to use RenderDoc for that. It isn't exactly quick to dig through all the per frame data but at least you can be sure of results and from there have specific data to dig further into what might be happening on the Unity side to cause any changes.

 

Agreed, I think it's likely to end up being configuration but I haven't been able to find anything obvious.

I've gone ahead and logged a bug ticket now so will see what I hear back, but your advice sounds good and I may take a look at RenderDoc when I get some more time. I've tried looking at the frame debugger in Unity and can see that there are more draw calls being made but found it hard to do sensible comparisons this way.

 

Which is why i suggest using RenderDoc as sadly the frame Debugger in Unity may be inaccurate or at least easy to misread. Note i'm talking as of Unity 2019.4.f21 here, things may have changed or improved since then.

For example I recently went down a rabbit hole on trying to determine actual number of drawcalls for a depthNormals render texture effect and there was a big difference between Unity and RenderDoc. Reason was some Frame Debugger drawcalls are collapsed into a single entry - you have to check the details pane carefully to see that what might be listed as a single drawcall batch is actually made up of multiple drawcalls ( DrawIndexed ) on the gpu.

I've noticed the frame Debugger can also change even though the project is paused when interacting with it. From memory I think I put it down to editor scripts running as executeAlways or something similar.

Anyway good luck with it - I know it can be a pain to go through frame data like this. Sadly I don't think there is a magic bullet unless there is a well known issue that someone might be able to point in your direction.

 

Advice much appreciated, thanks for taking the time to chip in and share your experience. If I manage to shed any more light on the issue or hear back from Unity I will post another update.

 

@arnaud-carre I can see that the bug report I filed has been reproduced, triaged, and is now logged in the issue tracker (1341189). Any chance the team there are able to offer any insight into what might be going on yet?

 

So, I've now been told by Unity support that this problem was caused by the apparent resolution to another bug which has to do with shadow culling, fixed from 2019.4.19f1 forward. See here...

https://issuetracker.unity3d.com/is...amera-near-clipping-planes-or-shadow-distance

So effectively, as a result of fixing that bug my project suffers an increase of ~12% rendered vertices in a scene which did not suffer from shadow culling problems to begin with as far as I can see.

I guess at least I now have some direction and will have to experiment with settings to see if I can reign it back in somehow.