URP Runs Slower than Standard Pipeline

Would shader batching + atlasing textures result in the best performance? Or is it an either or situation?

 

In my tests on the Switch, atlasing didn't improve framerate nor bandwidth. For moving objects I use SRP batching exclusively and nothing is atlased. Maybe 50x 1K and 2K textures.

 

Could this be because your game isn't CPU bound? This is a very non-intuitive result (I think)

 

I didn't think about that, it's a good point since SRP batcher is much more CPU hungry than built in.
Now that I think about it, this may be the case because when I turn graphics jobs off I lose 20% framerate and that is from the CPU. I'll know more in a month when I bring gameplay back online.

 

Well let me know! I'm going to update to URP and see how it goes.

 

Furthermore, you can practically use URP on low-end device that only support up to GLES 3.0. If and only if you not use real time lighting, and focus on optimizing baked lighting/shadow and light brobe.

URP have significant worse performance if use realtime lighting and shadow on weaker device. (I believe URP was built to give boost to baked lighting performance?)

I believe URP docs should provide extra info to explain what are limitations on Android devices. Because it seem like, most people reading URP not aware of all optimize technique to provide the best results.

 

What if I'm only using one directional light? Will I get worst performance?

 

on all test I did, with multiple settings, URP does run worse on a variety of devices (Android around snapdragon 820 - 2015?).
It does work well in new devices but again, some features are broke (as the frame optimize timing).
Saying that, the new post effect is one of the biggest issues, profiling it using Snapdragon, Adreno, Xcode and others we can see many GMEM Load.
Theres a sweet spot using Vulkan + post effects on mobile that will give good results but android have a huge variant of phones and we can't be constrain on those specific settings.

right now I will recommend writing on post effect and profiling asap, skip vulkan and go for OpenGL for more steady fps on all devices. Shader graph only for prototype and check all those checkbox in unity about optimization as some will break your game (feature is complete broke in some android devices).

The thing I hate most is that URP is constantly updating, even the inspector change, some times more properties, other less, some var are public, later hided... the maintenance of tools are exponential growing.

Sad thing is that my next project target device is inferior to Snapdragon 820... lol I was hoping to go full Genshin Impact, iPhone 8 level as minimum..haha

 

Many successful game developers still use the Unity 4 (real drift, drift zone, shadow gun , traffic ride ...) few of them was my friends and i know that using unity 4 for now!!! And they have not left it yet for their new games
And we are discussing here to abandon the standard pipeline and use URP
In my opinion, it is the best option for making mobile games is the Unity 4 !!! You may consider me crazy, but if I want to make a mobile game right now, I will use Unity 4
I have not made a game for 4 years
Unity has to unveil new tools to get more sales, but you can still use your own desired version or pipeline
Unity is still alive with a a lot of amazing versions (4,5,20Xxx)


My opinions :
1. for graphics and performance for mobiles: Unity 4
2. for Interior lighting : Unity 5 to 2020 and Built-In pipeline
3. for new devices and new technologies : Unity 5 to 2020 and Built-In pipeline
4. for asset store assets publishing : HDRP and URP and unity 2020

 

Custom pipe maybe? I got 720p@60 on Helio P22, with decent Overw-like graphics.

 

I completed my upgrade to URP and have in fact seen performance improvements, but I didn't run any controlled tests so there are likely many other factors at play besides the pipeline change.

Things that stayed the same
- Poly count of scene
- Texture size
- Game logic

Things that changed
- Reduced unique shader count to 1 + variations (simple lit)
- Order was changed to render arms and weapon on top of everything
- Shader batching is enabled, static batching is disabled

Results and conclusions
I'm seeing a ~30% increase in framerate. I went from 24 to 31 FPS on a Samsung Galaxy A5 and from 190 to 250 FPS on my desktop PC. On the built-in pipeline, disabling shadows had no effect. On my Samsung device while in URP, it adds an extra few frames. I'm finding it much easier to use a small number of shaders in my scenes instead of atlassing textures for extra performance. With these changes and dropping the rendering resolution to 80%, I can now get a comfortable 40 FPS in my test scene. Overall pretty happy with the results

 

I finally got around to doing a head-to-head comparison between the built-in renderer and URP. I used a very basic test scene, containing a 3rd person character standing on a simple cube, with no terrain, vegetation, or water to complicate things. My test platform is Unity 2020.2.6 running on a mid-range Windows 10 machine. I converted the post processing to URP, added bloom, shadows, and vignette effects - to visually match my original project as closely as possible - and set materials to URP/Lit, but otherwise left everything the same. Resulting frame-rates were significantly lower, as was render quality.

There are still some features that URP lacks compared to the built-in renderer, such as ambient occlusion and light flares. I read that AO is coming in the 2020.2 release cycle, but don't see it listed in the available effects yet. All in all, while URP may be the future, it's not quite there yet, at least for me. Maybe it scales better to larger, more complicated scenes, and maybe with the right optimizations, it's possible to squeeze more performance out of it, but I haven't found any clear and simple guidelines for doing this yet, and am not prepared to figure it out by trial and error. So while I'll be keeping an eye on URP as it evolves, I'll continue using the built-in renderer in my main project for the time being.

 

Ambient Occlusion is in the render features, not in the post processing in URP

 

Thanks. So it looks like some of the old post processing effects will be in the renderer now, just to make finding them more fun. This wasn't mentioned in any of the guides I followed when setting up my test, so I didn't even think to look there for it. This brings up another issue - and another reason to hold off for now. While I'm fairly well acquainted with the built-in renderer, and there's lots of information available on it, URP is still a bit of a mystery to me. The stuff I've found so far is either overly technical, and hard to parse into real-world work flows, or overly simplistic, and missing important details like this. I don't need to know all the underlying principles behind it, just practical implementation guidelines that cover a few more features.

Another hitch I ran into was converting the standard materials in my scene to URP. While a wizard was available to do this, in practice, it missed a few. This meant manually assigning the URP/Lit shader, and then re-applying textures to about 10 materials in my test scene, since they seemed to all get stripped in the process. I shudder to think what would be involved converting the hundreds of materials in my main project. URP is still fairly new though. Once it's more mature, and more information is available, it might be worth another look.

 

Converting materials to the URP is not too much hard. The material settings are almost equal between the two pipelines
But in HDRP it is completely different

 

True. One of the main reasons I'm looking at URP. Which is why I was a bit surprised that the wizard wasn't able to do it automatically for a lot of them. The problem comes when there are thousands of materials in a project, and 10-15% need to be done by hand. Not that hard individually, but a major undertaking to fix them all. I don't have a team to delegate stuff like that to. It's all on me.

 

I think you're talking about custom shaders. You only need to convert them once

The main problem is when you want to convert your project to HDRP, you have to review all the materials again.

 

I'm talking about anything that doesn't use the Standard shader. I'm not sure what you mean by "you only need to convert them once". In my case I needed to reattach textures to each material that wasn't successfully converted by the wizard, because the textures were all missing after assigning the URP/Lit shader to them. So that would be a base map, and possibly a normal, metallic, smoothness, or height map for each of potentially several hundred materials that might be affected in my main project. Unless I'm missing something, I'd need to do it once for each of them.

 

You can write a simple script to batch convert your custom materials and assign slots automatically

 

You may be able to write a simple script to do that. I'm not sure I can. It's all academic anyway at this point, since as I stated earlier, I'm sticking with the built-in renderer until a few other issues are taken care of. Material conversion is just one of them.

And if the script is that simple, it should probably be provided by Unity. Whenever they introduce a new way of doing something, you can bet they'll deprecate the old one eventually, so I expect the built-in renderer won't be around much longer. If they want people to embrace their clever new system, they need to make it better than the old one - meaning having at least the same features and performance - and make the upgrade path as painless as possible. So far URP seems to do neither. Of course mileage will vary on that, so I'm only speaking for myself.

 

I too went back to standard render pipeline after i was unable to achieve the same framerate using URP on old and new Android devices.

 

Unity can not write the conversion script for you because each shader has its own keywords
Anyway, I'm a fan of built-in myself, and I use URP and HDRP for fun, not game development
comparison:
https://forum.unity.com/threads/hd-rp-vs-built-in-pipeline-performance-comparison.526509/page-7

 

Hey, I have been getting the same results and was about to make a post.

And I didn't even consider using Unity 4 to make my game. How does it different than Unity 5? Is it less bloatware?

I have been eyeing a few assets to experiment with a game but they are URP only... URP has issues stated in this thread, just forget about it and only focus on Standard Renderer Pipeline assets? What do you all think.

It's this asset:
https://assetstore.unity.com/packages/vfx/shaders/stylized-water-2-170386

I'm not sure I'm prepared to make the leap to URP..
are there like really good posts / blogs for diving into URP and maximizing performance for total noobs to it? Just installing it and testing base scene seems to show how limited it is not how performant it is to me.

 

My opinion:
1. Forget unity4. it's just good for older unity developers...It's not free
- Fast baking
- Default settings is maxed out performance
- Bake into the prefab
- Export on android 2.5+
- Load faster... build faster...
- You can not make non-optimized game in unity 4 !!!

Unity 5 built in pipeline is good when optimizing the settings for maxed out performance : see the link

2.There is no difference between Standard pipeline and the URP in quality or effects
So the standard pipeline is a better option with more features and fewer problems

3. In my opinion, it is too early to switch to URP/HDRP for production games

 

My information is for 1-2 years ago on mobile game releasing
It may no longer be possible to use Unity 4
Anyway, I'm sorry if I gave the wrong information

 

I have a long living game in Google play and App Store that's been regularly updated from 2012 to today. I have always hated upgrading unity versions because each major upgrade causes my players with older devices to lose performance and eventually have to be dropped.

I remember in 2013 I was thinking, wow with devices getting better each year, soon my game will be running perfectly on any mobile devices! I was wrong. Well I was right if I never had to upgrade unity versions but that's not possible in reality. Each year or so, Google or Apple will have new technical requirements that is only supported by newer unity versions. If that didn't force you to upgrade then some 3rd party assets or libs will.

So yah, I agree that unity 4, or even 5 would be best for running mobile games and I wish I could keep using those. I mean my game doesn't need most features in new unity versions as it's a cartoony game and c# alone is enough to keep improving the game. But as long as you have to publish your games to an AppStore or monetize it using 3rd party libs, e.g. IAP or ads, you will need to upgrade unity more often than you'd like.

 

Last time I tried LWRP on a low end device it was much slower for my game compared to built in. That was in 2017. Based on all that I read, it is still not worth migrating yet. Perhaps in another year or two, when either unity fixes it, comes up with another solution, or when devices catch up.

 

This is a problem at any work and causes the best tools to fall
For example, NFS Most Wanted 2005 was the best arcade racing game, but with the change of the next generation, it could not synchronize with the new graphics and failed

Yahoo Messenger was popular but could not remain popular

Unity 4 was also the best tool for mobile , but ... it had to fall

I can optimize the latest version of Unity to the level of Unity 4 because I have a lot of experience (I have made 30 games for mobile) but most people have a hard time with new versions of Unity and can not make optimized games for mobile
With a simple wrong settings or shader, the whole performance will be killed ... Unity 4 had no any non optimized settings or shdaers for mobiles!!!



Unity 4 runs easily on older laptops, but the latest version of Unity is very heavy ...
You need to have high-end systems to work smoothly

The policies of Google, Apple and Unity in the field of mobile game development are very wrong and it is clear that they have no real experience in game development.

 

True, epic games added the tools used to make fortnite better on mobile to their game engine and now UE4 has better support for mobile then it had before just because of that game.

 

I also noticed.


By default somehow it stuck at 30fps in urp.
Use this code to get 60fps or whatever fps you want.



public class FrameRate : MonoBehaviour
{
public int target = 60;

private void Start()
{
QualitySettings.vSyncCount = 0;
}

private void Update()
{
if (target != Application.targetFrameRate)
{
Application.targetFrameRate = target;
}
}
}

 

Better not to say SRP. SRP means scriptable render pipelines which are URP and HDRP. Maybe you were mentioning the legacy pipeline which unity comes by default.

I still love legacy pipelines for real-time global illumination (No volumetric light) URP and HDRP lacking this. Still, there is no perfect solution.
Unity lighting system still sucks to me, Unless you are a good shader artist you need to take a lot of hassle to create appealing lighting

 

There’s no forced 30fps cap on mobile: vSync is always engaged and vSyncCout has no effect on mobile, so if you can’t hit 60, the game simply drop to 30fps.

Also, you don’t need to set the targetFrameRate in Update: it’s enough to set it once.

 

Bakery for lights is good, HDRP & URP will get enlighten (real-time GI) in the next update I believe. Should land in alpha after a few alpha versions.

 

Hi I couldn't find the exact thread for urp bug I'm experiencing with. So I'm posting it here hoping someone will see and help me.
So I'm experiencing a weird bug couldn't identity the source as it only happen for power vr devices using vulkan api. While the same scene works great with adreno devices no issues.
I'm using Unity 2019.4 build platform Android vulkan and open gl es 3.2

 

April 2022. I've spent 2 weeks migrating my project to URP for android... results: don't. It sucks.
Terrain shader took 50 mb in memory. Runs at 1/4 the fps than the default built-in shader.
URP Lit Simple took over 40mb in memory. And it runs 1/8 the fps of a simple shader on the previous pipeline with the same quality.

Summary: You spend a fortune on new assets for URP, take weeks of work to migrate to end up with a game that looks the same than before but runs out of memory on most android devices because the shaders are so large, and it also runs at 1/4 the fps.

 

That is my experience also, URP is slower in actual game environments in general, even more so in desktop where the image effects are implemented much slower as well than Standard.

The shaders have totally unneeded overhead and are needlessly complex comparing to standard.

HDRP is even worse too. The pipelines is the most useless thing i have ever seen and this comes after investing years in my assets in both URP and HDRP.

Then again, everything good about Unity goes worse, i migrated to 2020 lately one project and the editor is now close to unusable, with constant wait times and pop up windows, it is like Unity wants to go out of business or something with all those superficial moves that focus on bringing in new totally broken or unneeded things, than focus on their previous strengths, which were true multiplatform development with a single code and shader base and fast stable editor.

 

If we have to say one is useless, I'd argue URP is the useless render pipeline.
What does URP accomblish that built-in doesn't? After a few years of development, what is there to show?
No graphical advantages (the opposite), no TAA/SSR/Cascade blending or alternative/LOD crossfading, all exists on built-in. And URP feature quality is more or less the same as built-in.

In truth from my tests URP performance on PC was in parity with built-in, sometimes slightly better, but from developers I've talked to it has much worse mobile and switch performance (to the point where multiple devs switched back to built-in and gave up on URP and it's shader variant hell).

To top it off, it has less asset support, so the community can't make up all it's faults as they did with built-in.
In built-in you can next-gen shadows, no alternative for URP. The developer of next-gen shadows attempted to switch to URP but gave up due to a bunch of issues, including performance.

At least HDRP brings something unique to the table for PC users.
And if we don't get TAA by 2022, we'll have to wait until 2023. It's always more and more waiting.
SSR isn't in progress, so who knows what's the story with that. Maybe 2025.

And lately unity only releases 1 feature update per year (.1 has little to no features)..

 

Both SRPs also have a significant design flaw: pretty much all of their C# code that setups passes, prepares command buffers, shader parameters and whatnot has to run on the Unity main thread, which is usually the bottleneck on any Unity game.

This can quickly nullify the gains from the cheaper draw calls produced by the SRP batcher as your scenes scale up in complexity, and makes the SRP logic compete with your Monobehaviour code for main thread time.

Unity should have designed the base SRP architecture to run on a separate rendering thread from the start, kinda like that magic function that runs on the audio thread.

The way it is, it will be really hard to scale games using either SRP up to large and complex worlds. This is already a problem with HDRP, which has a significant CPU load that makes it barely usable on last gen consoles (PS4 and Xbox One) and unusable on Switch.

 

Yep, I understand if URP was in version 1.0 beta or even 3.0... but it's already in version 13 and still sucks compared to built-in. It's ridiculous that my game just keeps getting slower without any additions just by "upgrading" to new unity releases. My game ran at 50 fps in an iphone 4 with full quality compiled with Unity 4. Those same settings with no new content today is running with unity 2021 and URP at 10fps on an iphone 7 and needs x10 the ram. Wtf, seriously.

 

The question is why are they still developing another render pipeline if literally no one asked for it and also runs slower?

For those who say that the problem is to develop for older devices, you are just trying to find excuses. Modern devices can also benefit from lower resources usage (better visual quality, battery usage, etc...)

 

The reality nobody in this thread is talking about is that URP is actually faster, when it's configured properly. If you try to convert an existing project and change no settings, URP will be slower. If you start a fresh project and ensure all of your settings are reasonable and all shaders are SRP batcher compatible, you will be much faster in the long run. If I were Unity, I would have encouraged new projects be started in URP and existing projects stay on built in. Their decision to try and get everyone to upgrade their projects was a huge PR mistake.

 

From all my tests so far the URP is a lot slower when it comes to handling image effects, the same effect is just slower when implemented through the URP stack, making it rather a terrible choice over standard imo

Maybe was faster before they added all features, but it still misses features like replacement shaders in material input and image effects seem radically slower so far.

I wont even go to HDRP that i wonder how would anyone decide to use it in a game with such crazy overhead. For sure URP is not the worst option .

 

From my experience, URP optimized can be as fast as built-in with almost no optimization. And that's the problem, you need to optimize URP like crazy to achieve what you could already achieve with no effort. And once you also optimize built-in, I have yet to see URP outperform built-in no matter how much you optimize it. By design, it's just slower.

 

In my case draw calls were decimated and fps skyrocketed by switching to URP due to the new batcher, if you have a lot of materials based on graphs then it makes them cost almost nothing, my fps almost doubled without doing anything.

 

Ultimately it depends on where your bottlenecks are. If you are GPU bound (aka: low end mobile, mobile VR), the stuff URP has enabled by default will hurt. If you're CPU-bound due to sheer number of renderers, URP wins out.

 

Then change your settings from the defaults! URP has post processing on by default, if you're developing for low end mobile you should turn it off, and you will have better performance than an equivalently featured BiRP game. People are just trying URP with defaults and not changing anything and acting surprised that the performance isn't magically better. If you're sticking with defaults and not doing any research, you deserve a slow game.

 

I see a lot of going back and forth. I'm all in for built-in is faster than URP when you optimize both, and I have no doubt about it after more than 12 years of developing using Unity.

This is simple, if you believe strongly in one position, let's just have a contest. Upload a project you believe that is faster in URP than built-in and make it open source. We can then rewrite it using both systems and compare the results. We would use Mobile as a benchmark since it is where it is most obvious performance impact.

The project must include:
- Large number of gameobjects / renderers.
- Real time lighting with shadows.
- Terrain with trees.

At the bare minimum. Because it is not fair to compare a rotating cube or a simple project batching 100 cubes. It has to be some kind of realistic 3d in game behavior.

We optimize the project as much as we can using both render pipelines but we must stick to the same resolution and as much as possible quality settings. Opengles 3.0 for mobile, since Vulkan driver performance varies A LOT from device to device. And obviously, the same Unity version. Then we measure:
- GPU and CPU performance.
- Achieved frame rate.
- RAM usage in the mobile device.

We then need to setup some rules on what we are allowed to optimize and what not. For instance:

Allowed to optimize since we are trying to compare the render pipelines:
- The shaders. We can write all the custom shaders we want and optimize away on each pipeline.

Not allowed to optimize:
- Polycount of meshes. Since it has to be the same for both pipelines.

Maybe also add some checkboxes to enable/disable features to compare. For instance:
- Enable/disable batching.
- Enable/disable shadows.
- Enable/disable real time lighting.

We create a table with those checked and unchecked for each render pipeline. I'm sure at some of them URP would be better and Built-in at some others. Then people can decide which one to use depending on their use case.

I believe this would not only settle the debate here but also help Unity see what's causing all these constant complaints about URP and hopefully finally do something about it.

Anyone up for the challenge?

 

URP sucks in mobile game production, use it only for hobby/learning purposes.


I managed to get the same performance only on my android phone with Mali-G72 GPU and disabled SRP Batcher
BUT . .
On other devices you get.. PINK issue, stuTTer, MIScoloration, gLitCHy sHadows, plus 5 thousand more glitches..

I got a lot of 1-star reviews from PowerVR GE series users because it's basically unplayable so I had to exclude them from Google Play Store and oh boy looks like I'll be losing millions of users because every fricking phone has PowerVR GE AHH

soon I'll spend a month just to downgrade everything, or I'll just leave it like that forever :cry:

-URP v7.7.1, 2019.4.4f