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

Thanks for dropping by!
I've reported a bug with 5 test projects attached that I used to compare performance: Case 1202538

 

Its faster but not backwards compatible, and custom post effects are not yet supported.
Do you know when they will come?

 

Can we have some numbers from BoatDemo for example as it's seems to be the main demo for testing

 

Were anyone in the Unity team able to test the projects I've attached with the bug report?
Each project is using a different Unity version, a different render pipeline or a different post processing stack, but the scenes are the same and the settings are the same. So it's should be simple to check performance for each combination of Unity version, render pipeline and pp stack in basically the same conditions.

 

If URP not for mobile, so which one for mobile? HDRP?
sorry, if not mobile, please use HDRP.
If URP and HDRP both for high end hardware, is that mean srp not for mobile?

 

Write your own pipeline

 

@Andre_Mcgrail
Thanks for a detailed reply!
I haven't tested this on iOS yet. I will try this next.
Here are the profiler screenshots from my Xiaomi Mi A1 phone.
As you can see, it takes almost twice as long to render the frame in 2020.1 URP vs 2018.4 built in.
Also, just switching from 2018.4 builtin to 2020.1 builtin - the difference is huge.

I've tested this on 2 different phones, Xiaomi Mi A1 and Nokia 6.1. While Nokia is slightly faster, the trend is exactly the same.

Built-In - 2018.4.3f1 - ppv1 - Standard shader


Builtin - 2020.1.0a13 - ppv1 - Standard shader


URP - 2020.1.0a13 - Lit shader


URP - 2020.1.0a13 - Simple Lit shader

 

Is stop NaN unticked?

 

Yes. Stop NaN is unticked for those last profile screenshots.
I've tested enabling and disabling Stop NaN and the difference is ~1 frame per second, so it's definitely not the main issue here.

 

(Offtopic) That's not true nor how performance should be looked at. You could be stressing ALU but bottlenecked by bandwidth, or the reverse. It can bring things close to a tipping point, especially with vsync. Please don't dismiss things like that, which are taxing the GPU in different areas, they will come back and bite you.

Also what's the ms cost? nobody cares about FPS because FPS is a gamer's metric. For example lets say NaN is not the bottleneck here? add 1 single shader that does tax ALU elsewhere and absolutely would be the problem but you'd have already decided it didn't take any performance and blame the new shader instead....

 

I've tested 2019.3 as well, which is almost identical to 2020, so I haven't included it in the bug report.
Here are the results for 2019.3:
URP - 2019.3.0f1 - Lit shader


URP - 2019.3.0f1 - Simple Lit shader


Frame Debug 2019.3 URP


Both devices are running Android 9, API level 28.

 

I think the message for the Unity team is to share these deep-dives with us as much as possible. Statements like "When upgrading a project from the built-in render pipeline to the Universal Render Pipeline, you should expect similar or improved performance" might very well be true, but we should see detailed information to back it up.

I also think we need more URP hero project examples.

 

I got a reply from Unity that they were able to reproduce the issue and the case was sent to developers for further investigation and a fix.
I hope this actually gets fixed.

 

Did you get a case number, so we can track the progress in the public issue tracker?

 

Case number is 1202538, however I can't find an entry in the public issue tracker.
Is there a way to search by ID?

 

Thanks! Here is the link to the public issue tracker:
https://issuetracker.unity3d.com/product/unity/issues/guid/1202538

 

I voted too.

 

Any update on this?

 

I am having similar issues on my project too. When enable post processing in the camera and testing on an Android device my frame hate drops by ~20fps even without any volumes in the scene.

 

For me I only have the drop of 20 fps (over 60) when using Bloom on a Samsung Galaxy S7.
Not sure if it should cost that much.

 

Thank you ! You made my day

 

Thanks for the update, Andre!
Unfortunately I can't say I'm relieved.
It feels like the issues that are causing the performance regressions are complex to the point that no proper fix is coming in a foreseeable future or coming at all. I somehow doubt that the confirmed quick fixes (available when, in a month, two, three?) will have any noticeable impact. I'm also not interested in complex PP effects, that could be optimized by reducing quality.
This kind of leaves me with built-in renderer and PPv1, since the breathtaking performance dip experienced with URP+Post probably won't be fixed anytime soon.
:sadface:

 

Is there anyway to remove the post processing completely as of now? Is it currently impacting performance even if post processing is disabled on the camera?
I am doing post process through a Blit render feature, I wouldn't want the additional cost of the builtin Post Processing solution as well.
Whats the best approach for the time being?

 

@deverolirc "any" way - yes, you can modify URP as you need, including kicking out whatever passes you definitely don't want. With a bit of carefulness (and git rebase) upgrading is still possible albeit of course much less comfortable than just upgrading URP directly.

 

I would hope there is an alternate solution to this, will wait to hear word from UT before I get tangled up with modifying the pipeline.

I am curious about the performance contrast between "completely" disabled vs disabled via the camera toggle, how substantial is it?

 

Depending on the platform, the performance difference can be huge. Upcoming versions of URP are supposed to finally fix that, but so far even with PP completely user-disabled there were extra (unnecessary) blits and render passes on e.g. Quest, Hololens (where perf really matters).
Waiting for an official UT reply might not be the best strategy depending on your timeframe, XR communication is ... minimal. If you get an answer it'll probably be "next version fixes all XR issues" and then in the next version sth else breaks (at least that's been the situation for me for a year now).

 

How big of an impact does a Volume system have currently and how much performance boost can we expect from disabling it? Will it have any noticeable impact alone?

 

Thanks, so disabling it via the camera will disable the pass, only issue for now is that the post processing resources are included in the build?

Also curious about this --

 

While 2ms is huge, unfortunately it won't help my FPS going from 60 to 26 when enabling LUT color grading.

 

LUT color grading will enable fullscreen blit passes. This will kill performance, as you see. Don't use this on Quest

Also @Andre_Mcgrail the postprocessing Uber shader alone adds more than 25MB to a Quest build if not manually removed from every place that references it. "Few kilobytes" is a huge understatement

 

And this wasn't the case with built-in + PPv1, where I still get stable 60fps?

So, the time frame for a fix that might make URP+Post usable for me is ~6+ months?

 

@phil_lira Wasn't exactly sure what you meant by framebuffer capture.
I'm attaching the frame debugger for PPv1 and PPv2 for comparison:



Let me know if you meant something else or if you need more info!
Thanks!

 

This seems interesting, I haven't found where I can get ppv1 is there a download link somewhere? On the git im not sure which branch to get if v1 is on it. I'm on Unity 2018.4f1 and using PPv2 Bloom and Blur effects, but on Switch it cost between 7 and 10ms for both effects (losing the 60fps target).

 

https://github.com/Unity-Technologies/PostProcessing/tree/v1

 

Readme: This branch holds version 1.x of the post-processing stack. We recommend you use version 2.x as it's more modern and is being actively worked on.

 

LMAO

 

So I hate to bump an old topic: but i'm using Unity 2020 alpha (2020.1.0a25.3171)

The game I am making is cross platform (Android, PC, Mac, and Linux) using the URP and the built in post processing within URP, and with standalone builds the game runs great. But with the android build (built using IL2CPP) when I am in a menu (no post processing) I am getting 60 fps. My level creator also gets 60 fps (no post processing). But when I switch to the main game I drop to 30 fps with my Google Pixel 3a. HOWEVER after a couple seconds the fps will spike back up to 60 fps and hold there until I go back to the menu and into the main game again. Note my game is built using only ONE scene so the amount of objects in the scene so switching to main menu, level creator, and main game means the only difference is the main camera enters a sphere collider that triggers post processing.

 

Kudos to the effort by @Devil_Inside in clearly defining a test case.
Myself I have noticed a consistent drop in performance without quite being able to pinpoint exactly how or why... with no time to see the underlying issue, just trying to go around the issue by game design changes or disabling features altogether (which were fine before even older devices).
If I'm making a game, I'm trusting what the engine devs tells us, if something goes wrong I'll assume first that it's my fault since everywhere it's advertised as "faster, better, stronger!"
Thanks again for taking the time to make clear steps, most people don't really have time to be digging in like that.

 

I wonder if any improvements has been made with URP and postprocessing in regarding to this performance issue.
I think I am also getting it using 2drenderer with URP... In my case, I am running it on Switch, so I can't confirm for the mobile case, but since Switch do share similar performance issue as mobile, I am assuming that the same performance issue is still there. I am rendering relatively very simple 2D scene, but getting like 10ms rendering across 2 cameras, the actual rendering may not be that long, but CPU time that takes per each camera to render takes around 5ms each , no matter what it is trying to draw.

I am pretty sure that when I used legacy rendering pipeline, it was not this slow.

 

You can check this post:
https://forum.unity.com/threads/universal-rp-status.826323/page-3#post-5775334

 

I buy a lot of screen space image effects from the unity asset store.

Some are components directly attached to the main camera and others work through the post processing stack (I’m using ppv2 in unity 2019.2)

I’m thinking ahead and I don’t want to get stuck unable to update. It’s been mentioned here that ppv2 is going away. Does this mean current image effects I bought likely won’t work with ppv3 unless the devs update them?

To avoid this I am thinking that it will be better not to use image effects that use unity’s post processing stack because they are more at risk of obseletion, and I should stick with image effects that attach directly to the camera because they bypass pp stacks.

Does this sound right and does anyone have any suggestions or ideas about how best to approach this?

Edit: I should mention I only make games for iOS/Android platforms if this makes a difference