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

That's great but you are not comparing URP to BIRP. What about older Unity versions vs 2021?
Although, you seems to have achieved your target FPS, my situation is kinda different. We are starting a new project in a few weeks and we need to decide if we keep BIRP for the next 2-3 years or if we go with the "modern/scalable/performant/flexible/modifiable" one, the URP!
OK, that was a bit sarcastic, all in all is quite simple, we are pushing the Switch hardware a bit too much (doing full frame rendering, multiple dynamic lights with shadows, custom post processing and shading models, etc) and I can't even reach stable 30fps with URP. With BIRP im currently at 50-60fps with everything maxed out.
Unity keeps telling me to not use BIRP because it will be deprecated in the future, is legacy, is not maintained bla bla bla, URP is better, modern, scalable, bla bla bla but my tests tells me otherwise. URP is a slower version of BIRP with less features...

 

I don't like the deprication idea, for the simple reason that more than 90 percent of assetstore assets are made to work with BIRB and far less for URP

 

Wish list that will make BIRP obliterate out of the water any SRP renderer (even more):
- Make the SRP batcher compatible with BIRP

Bonus list:
- Extends BIRP so we can add custom passes through C# to the BIRP pipeline (this is already achievable using command buffers but something more abstracted such as the BIRP post processing system. Remember how easy it was to do post processing with OnRenderImage? Well something like "OnRenderScene" with similar calls such as the ones you do when writing custom render passes in HDRP/URP (with Setup, Execute and Cleanup calls) and an option to define the injection point.
- Allows us to replace BIRP passes, or remove them completely

This is more or less what SRP do but this solution doesn't require you to fragment Unity into three render pipelines. My understanding is that the drawcall batcher is decoupled from the BIRP code, why wasn't this option viable since the beginning? Is BIRP code so bad that you can't remove forward/deferred paths on it?
In any case, are we late for this or im still hoping for the impossible here?

 

I doubt they will deprecate built-in anytime soon. The fact they are adding built-in support for shader graph hints they know URP adoption hasn't been up to what they expected.

 

RyuJIT significantly outperforms both IL2CPP and Mono, so hopefully .NET 6 will let us eek out a tiny bit more performance from SRPs: https://github.com/nxrighthere/BurstBenchmarks . And that doesn't cover the real killers of IL2CPP and Mono perf which are virtual/interface method calls and GC. Unity's upcoming .NET 6 integration should fix the former. GC is going to be non-moving, but hopefully it'll be a little better than Mono's GC which is benchmarked at about 40x-200x slower than CoreCLR's.

Ultimately, though, I agree with @Neto_Kokku -- many of Unity's APIs need to be multithreaded. ECS is an extremely heavy-handed solution that requires rewriting tons of code (both for Unity themselves and for developers). But the real issue I see with having ECS as the only path for good perf is that it damages the whole quadrant of Unity's intangible capitol advantages over Unreal:

1. Ease of scripting
2. Extensible editor (try working with entities in edit mode...)
3. A wealth of existing tutorials/learning resources
4. Existing extensions on the asset store that fill gaps in the engine

And even in ECS, I believe content streaming (eg loading meshes and materials) are locked to the main thread. As long as major parts of the core (C++) engine functionality and low-level APIs are single-threaded, these bottlenecks will remain. Which puts a cap on what can be done in an SRP, which only BIRP can get around.

I don't think asking devs to write C++ plugins is the right idea, and Unity would never do it anyways since source access and enterprise support are how they make money. The solution that's been staring them in the face since 2005 is taking parts of their existing APIs and making them thread-safe or moving them off the main thread.

 

Totally that, even if URP can be optimized somehow to reach BIRP performance levels, I still have to port all my shading models and post-processes to URP which is a ton of work.
But even if we decide to stay with BIRP for this project, I will provide Unity folks some stripped down versions of my project so they can do tests. In fact, I already got a smaller version of my project (10GB) running on 2021.2 with URP12. Right now I'm doing the same but with Unity 2019 and BIRP / URP 7.7. So three versions of the same project with only one scene using 3 renderers for them to try any kind of regression and performance difference. I waiting for the upload link to provide them all three projects.
In the mean time, I'm going to work on an optimization that can potentially make BIRP a lot faster and I will open source it if it works properly. Is a depth copy from opaque pass (basically only pay the cost of resolving depth without having to render your scene twice). In theory this should work with any BIRP shader as is only resolving what your previous passes wrote to the depth buffer. There's also others similar stuff that can be done on BIRP to increase the performance gap a lot more but that can be a subject for a new discussion.

 

Whatever you're doing - ship it and reboot your rendering for the next game or sequel in URP. Please!

I had a brilliant PS4 game going in built-in. Top performance, everything then I got blindsided by what Unity was promising with HDRP and failed to ship.

Having learned my lesson on this, I tend to stick to one engine, one pipeline, until something ships!

 

I already got three branches of my project running in three different renderers (2019.4 BIRP/URP7.7 and 2021.2 URP12).

Well, I got three branches (or versions) of my project, the resulting of all the testing and porting i've been working on the past few months. Only thing left to do is to port my custom shading models and post process but I'm going to wait for that.
If (big if) all the URP issues are fixable in a reasonable time maner, I will use URP on our next project (the one starting soon).
My other option is to port my custom BIRP renderer to SRP. My custom forward renderer in BIRP is about ~1K lines long. Mostly light culling, uniform data setting and shadowmaps binding. Post-processing is also custom but decoupled from the scene rendering pass (which is a single pass forward path). Porting to SRP has some pros and cons, biggest con it takes longuer. Biggest pro, using the SRP Core libraries gives a good head start (eg shadergraph and SRP Batcher compatibility) and will benefit from future improvements to the C++ batcher and low level API improvements. I'm sure I can write a smaller renderer that outperforms URP because lot of URP features are not needed in our game, So a custom solution can fit our art pipeline/direction needs better.
If none of the mentioned is viable (time sensitive, performance, etc), then I still have BIRP but my project is 2-3 years long, I'm not even sure BIRP will hold on for that long. Though spot to be now.

 

I didn't know Shader Graph worked with built-in... finally! Now for volumetrics + PCF shadows + physically correct lighting (anyone know an asset?) = no reason to use URP or HDRP.

I'm curious to why anyone would use URP when you can make mobile games with realtime shadows on cheap phones using built-in, and also scale up desktop-quality to release on Steam... I have a 60fps 3D mobile game in development with 200+ pathfinding ai's. It runs at 60fps on a Snapdragon 665 Redmi Note 8T budget phone (~£145 a year ago) on built-in.

 

I believe once Unity moves the whole SRP to DOTS, then perhaps it will make sense to use SRP. Right now, im not quite sure. But let's say SRP DOTS is great and brings some significant performance improvements. How flexible the pipeline will stay? What new changes/breaks will introduce a SRP on DOTS?
So many questions. Betting on Unity future right now is like playing Russian Roulette.

 

Is the plan to move SRP to jobs threads? Current hybrid renderer (DOTS SRP) still runs render passes on the main thread.

 

That's the idea yeah, dispatching and binding GPU data from jobs. What is not clear is if that's going to be on the C++ side (Batcher/Scene Graph) or in the C# side (SRP).
Either way, my guess it will run below SRP (whether is C# DOTS or C++), cause SRP is more of an interface to the scene graph/batcher, like a giant command buffer. Making SRP more complex will destroy it's main purpose. It should remain as it (a scriptable object that allows you to define rendering passes). But allowing people to optionally manage GPU data binding/handling is great.

 

https://issuetracker.unity3d.com/is...12.1959525436.1638526904-750971283.1634143937
Is this what's causing performance regressions both in HDRP and URP

 

That's not good, maybe 0.1-0.2ms overhead or something. For me it would be too much in VR. It's a completely unacceptable cost. Should feel like 0.05ms if that.

Assuming https://docs.unity3d.com/Packages/c...nes.core@13.1/manual/render-graph-system.html

So it's basically unknown if it will get fixed, and are you sure this is an URP problem?

 

URP regressions are something else.
URP is not using RenderGraph to handle resources, at least not in v12/13. I did an extensive research in the URP githup repository and found no traces of RenderGraph APIs. For now* is only HDRP and I believe is an attempt at scaling HDRP more than few show rooms demos or low quality real-time CG movies. You know, for large scale games.
Although this performance hit is understandable (to some extend). Is normal that when you write high scalable systems like the RenderGraph to expect an initial payload/hit because you are using some of your system resources to smartly handle resources.
Think of it as Virtual Texturing. You can have large amount of giant textures in your scenes without having to worry about system resources. But that comes with an initial cost. It requires to constantly stream in/out tiles/pages in order to display the best texel size/mip combination possible and yeah is not for free.

 

As I said, profiling BIRP would require a huge amount of work and it really doesn’t make sense for us to do it. We’ve decided to migrate and focus on LWRP / URP in 2019 and we spent our time to learn working in SRP and make the best out of it.
It’s not been easy, it required a huge amount of work to get the best out of the pipeline, but now it really makes little sense for us to go back to the old pipeline.

We had no regression upgrading from 2020 to 2021. We’re currently on 2021.2.7f1 and the performances are the same.

Also: we’re pretty much working on vanilla URP as we used to work on vanilla BIRP, with no heavy modifications or special optimizations aside from hand made shaders. Would a heavily optimized BIRP outperform URP? I really don’t know, probably? But in the end it’s really about your specific scenario. I have a good feeling that by doing some optimizations to the pipeline + a custom made post process stack we could probably get 20% - 30% better performances on URP. At the same time, I’m quite sure that what we have right now would definitely not perform better on vanilla BIRP without a graphics programmer optimizing the hell out of it.

As I said, our approach is to optimize like crazy on the assets / scene side more than pure technology. We’re currently very satisfied with the look and performances on all platforms, so we have time in the future if we want to optimize the graphics pipeline and get more.

A couple more thing, IMHO:
1) with URP it’s a bit easier to avoid that classic ‘Unity look’ that plagues a lot of Unity indie games. When we showed our project to a Nintendo they told us: wow it’s a very nice use of Unreal Engine…

2) I think URP tends to scale a lot better with complex scenarios and lighting, while it tends to perform worse or similar to BIRP in simpler scenes. We’re still trying to push it, and adding more real time lights and shadows had a negligible impact on performances.

3) Using URP properly is complex, we have literally 10+ years of experience with Unity (I started using Unity 1.0, so go figure…), and it still required a lot of effort to properly migrate our pipeline and understand how to use it. So yeah, it requires works, also for experienced Unity teams.

4) Proper and optimized assets, the right light baking + meticulous placing of light probes and using all the tips and tricks really works wonder for the game look and performances and… yeah, this is the most expensive thing to do.

In the end, I think it’s very difficult to come up with ‘this is faster than that’, but I think it’s not good to just suggest to stay on BIRP “bacause it’s faster”. It’s an oversimplification.

Would like to share some screenshots of what we’re doing, maybe next week.

 

Can you explain the "understand how to use it"? It sounds like you found URP substantially differs to BiRP and you had to "learn Unity again"? What was most surprising and difficult during the migration for you?

 

Is this unity looking?


URP or not, 'look' is all about art and creativity, it mostly has nothing to do with the engine, nor the pipeline, that said, I imagine it would be a nightmare converting this shader into URP, and still run smoothly on low spec mobile devices

Is this means that URP is not 'production ready' nor 'newbie ready'?
HDRP is too heavy for non AAA game, URP needs a whole lot of optimization to run properly, and BiRP is getting deprecated, so what should those small new indie team use then?

 

Your point #2 is indeed an oversimplification. You are comparing URP to what exactly? You said you went to LWRP/URP in 2019. How sure you are URP scales better with complex scenes than BIRP? Have you tried?
For the past few months I've been doing testings with the same project (which is really big), different scenes, equivalent graphical features in three versions, Unity 2019 BIRP/URP and Unity 2021.2 URP. I have LLGD snapshots for all builds and clearly, frametimes are smaller in BIRP (resulting in higher framerate).
My testing results are, BIRP and URP in 2019 are very close (BIRP being slightly faster). URP in 2021.2 is slower than 2019 BIRP/URP all together. Worth mention that shader compilation for both BIRP and URP is about 10x slower in 2021.2.
In my tests, Is the other way around. URP scales better when the scene doesn't change much, there's little to no lighting, no depth textures, no opaque texture and no post-processing.
PS: Im not doing classic multi-pass rendering in BIRP. I have a single-pass multi-light custom forward, same as URP.

 

I'm not trying to dismiss your findings. Also, as I said, we've used pretty much vanilla BIRP and vanilla URP, so would a heavily customised BIRP like yours outperforms URP also in our project? I don't know, but probably yes?
But in the end it doesn't really matter for us: we, as a lot of other indie teams, don't have a dedicated graphic programmer so we can't super optimise BIRP or URP. We know that we have a lot of headroom if you want to do it in the future, but we can ship with what we have and be very happy with it.

My intention is to provide our experience, and in our experience we're quite happy on how URP performs all across the boards and we're very happy on the results. Reading these forums it seems that URP is simply a hog and shouldn't be used by anyone, but it's really not like that...

 

Don't get me wrong, I'm all for the art style over the engine / pipeline stuff, but aside for heavily stylised stuff, it's clear that if you're doing more a more 'realistic' PBR look or even aiming for flat shading a lot of Unity games has this kind of similar look. And it's pretty much boil down to bad art direction but also to teams just using standard Unity stuff.
It's the same with Unreal, BTW...

I think that URP is absolutely production ready. Heck we even shipped a game with LWPR on Apple Arcade (Secret Oops!)...

What should a small new indie team chose is a difficult question to answer: it depends on the scope of the project, on how much time you have, how much budget, the experience of your team and so on..

It you have to ship a game in six months and you know BIRP, stay on it, or you risk spending a couple of months just adapting to the new pipeline. If you have to ship a game in 2024 things changes drastically...

 

No it's not like learning Unity again, but if you're used to BIRP a lot of stuff is different, from small things like where the different quality options are (yeah it's a mess), to how to properly optimise your scene and materials.
Also keep in mind that we started on LWRP (shipped Secret Oops! on Apple Arcade on it, it was a mess), then got on to URP and so on. It's been a long transition to us.

Depending of the complexity of your project, it'll probably take you 1 or 2 months to properly master URP.

 

That's interesting! What optimization strategies did you find no longer work in URP and what optimization strategies did you find would be new to URP that didn't work in BiRB?

 

Quality settings has been moved from Project settings into the render pipeline asset
Material settings are the same in 99% of the settings
The other settings are the same
URP = Limited version of the Built-in to have higher performance on low-end targets...Safe performance settings for newbie users

The only things that can change the quality and performance are the following( and not renaming/rebranding the pipeline features):
- Color space (gamma or linear)
- Graphics API (dx 9 or 11)
- Rendering technique (standard or RTX)

When directx 9.c was released, the shader feature was added, which was a huge leap in graphics.
When directx 11 was released, a linear color space + hdr was used, which greatly influenced realistic lighting.
And now RTX can make a difference

So with renaming the features can not help the quality or performance

I love the URP as performance safe pipeline for mobile platforms. I don't know why users using URP for pc !

 

IMO, HDRP is just not an option for a performance-concious game on PC. Most Steam users don't have top-of-the-line graphics cards, so a PC game needs to scale to budget cards and lower-end CPUs. Really if I were looking at HDRP, I'd be seriously considering other engines at that point which are technologically forward-looking (Nanite...) and can scale better at the low end. Maybe someday HDRP will get there, but it does not feel like it really fills any niche right now except the "my team is already trained in Unity and we already have an enterprise support contract" one. Maybe arch-viz or prerendered?

Also, my impression of HDRP is that it's very centered around pre-authored levels and restricted camera angles -- so a single-player FPS or horror walking simulator would work great. But if you have a game with user-created environments (eg a city builder), or an RTS with hundreds of units on screen at once, HDRP will have scaling issues, and you'll have to turn off a lot of its features. And if you want a fast-paced competitive multiplayer game, you need to be able to hit 60+ FPS on a range of hardware, which HDRP won't do for you.

So, if HDRP isn't an option, that leaves either builtin (not being updated and can't use newer features like VFX graph) or URP. Or if you have the budget/team size, you make your own SRP.

 

if you’re doing a multi platform game you really doesn’t have much choice. HDRP doesn’t work on Switch and it’s basically unusable on PS4 / Xbox One.
So it’s built in or URP (or your own pipeline)…

 

For now, I will use built-in for the next few years

 

If you are on BIRP and uses Forward renderer, this might interest you.
I'm writing a C++ plugin that hooks into the Unity graphics devices adding native graphics function pointers to use them in Unity to copy depth buffers after forward opaque. Basically, it generates and replaces _CameraDepthTexture without having a depth pre-pass (avoids rendering the scene twice).
For now is just DX11 and DX12 but soon Nintendo Switch and PS4/PS5 using their respective native graphics device and contexts.
I will upload it on my github (minus consoles parts). If you are working on consoles you can pm/email me if you need an integration into your project (this one is a paid job). Im Nintendo and Sony licensee dev and have access to their SDKs and devkits.
Proof or it never happen.
Volumetric light using forward depth (notice the lack of depth pre-pass in the frame debugger):

Soft particles using forward depth:

SSAO using forward depth:

 

How do you generate the depth representation? Perhaps during the "base pass" via MRT? If it's not a pre-pass, I guess _CameraDepthTexture is only available for passes after "base pass"?

 

I don't. I use the one freely available after forward opaque pass and set it globally.
You need a C++ plugin that hooks to Unity graphics devices and a function pointer that does native ressources copies in the GPU.
Then in Unity you render the scene to a rendertarget (instead of the backbuffer) with a cleared rendertarget set depth (with 24bit). Pass that to the C++ plugin as a ressource pointers and do the copy call in the plugin. Inside Unity you will have a copy depth from the depth buffer. Then you draw a full screen quad to get that depth info as a color buffer (before is cleared out) and set it globally as _CameraDepthTexture (so all your shaders that uses it will work automatically).
In DX11/12 the ressources pointers are of type ID3D11Resource & ID3D12Resource. On Nintendo Switch is slightly different, you have to register the command to the command buffer queues of Unity. I haven't tried other platforms yet, but is kinda similar for all graphics APIs.

 

I found a way to do from Unity without any C++ plugin
In case anyone was wondering (a bit hard to see but that's the actual depth texture generated after forward opaque):


So the way to do it, you have to render your scene to a RT, more specifically, render the color buffer to a RTand the depth buffer to a separate RT. To be safe (and leverage Unity multiplatform power), set the color buffer to Default and depth buffer to Depth.
On editor (or more likely, DX11/12 platforms) the depth buffer is cleared by an unknown internal call that is not displayed in the framedebugger so you have to draw a full screen quad just after forward opaque to grab it. On consoles (confirmed on Switch and PS4) just setting the depth RT as _CameraDepthTexture globally works. Anything that runs after forward opaque that needs depth works like a charm.
I'm going to upload the script to my github soon.
I don't want to hick-jack the tread with my stuff but i feel like it kinda relates to the BIRP vs URP war as with this trick im currently sitting at ~56fps in BIRP vs ~32 fps in URP (on Switch hardware).
[EDIT2] There's other things coming into play about BIRP vs URP performance disparities on my project such as how shadows are handled in URP vs BIRP etc.
I have a custom optimized forward renderer, i believe if I re-create it under SRP, it might beat URP even more cause of SRP Batcher uploading GPU data only when needed.