The state of SRP coexistence

[Liam2349]

Regarding upscalers, it is pretty strange that DLSS is not supported for URP. You can buy an asset, but as is typical, it doesn’t support VR. If you want VR support for these more cutting-edge features, HDRP is the only option. It leaves URP in a difficult spot.

URP runs on everything, but on PC it is quite limited. HDRP is also heavy.

I get wanting to support multiple platforms, but PC users will want DLSS, and frankly, every upscaler that is not DLSS is quite far behind it and Unity’s STP will be no different.

DLSS is the single biggest performance improvement that can be put into URP right now, I don’t understand why Unity is not even planning it. Honestly though I would prefer if they dropped URP, made HDRP the single render pipeline (since it has all of the features) and focused on ways to mitigate its performance impact and whatever compute shader workarounds they need for mobile.

I am making a high fidelity open world PCVR game, and I am using URP because HDRP is heavy - but at the same time, this locks me out of DLSS. Some time in the next few months I plan to try porting back to HDRP to see if I can get good enough performance so I can access PC-quality rendering features.

[Ryiah]

@Liam2349

Regarding upscalers, it is pretty strange that DLSS is not supported for URP.

Skipping DLSS is at least understandable from the perspective of not wanting to have to make multiple upscalers to fully support upscaling, but FSR 2 is functional on basically everything and they completely skipped that too.

[sacb0y]

@Ryiah

Skipping DLSS is at least understandable from the perspective of not wanting to have to make multiple upscalers to fully support upscaling, but FSR 2 is functional on basically everything and they completely skipped that too.

FSR2 does not work on mobile and switch. There was one game that had FSR2 on switch but it was a modified custom solution specifically for that game.

@Jack_Martison

On the worst case introduce HDRP as baseline and Mobile RP with all features completely cutoff.

That is literally what they did, originally URP was called LWRP and was basically just for low end/mobile. But then it became an evolution of BIRP (as far as I’m aware there’s no native features on BIRP that don’t work on mobile/webgl).

In the long term I think the unification will effectively make it more like this, where URP is more like HDRP without any non-universal features (or just versions of the features that work universally).

@Liam2349

I am making a high fidelity open world PCVR game, and I am using URP because HDRP is heavy - but at the same time, this locks me out of DLSS. Some time in the next few months I plan to try porting back to HDRP to see if I can get good enough performance so I can access PC-quality rendering features.

I get HDRP can be heavy but it doesn’t exactly HAVE to be, some games have released with performance issues but they reasonably got resolved after launch without scaling back too much.

But I think Unity 6 made some solid improvements from my tests.

[Ryiah]

@sacb0y

FSR2 does not work on mobile and switch.

There is at least one implementation of FSR 3 running on Android (Vulkan), iOS (Metal) and Switch.

https://discussions.unity.com/t/899179

So it’s doable it just isn’t officially supported by AMD, but then AMD doesn’t officially support anything but DX12 which is clearly incorrect seeing that it’s running on more than Windows and Xbox.

https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK/blob/fsr3-v3.0.3/docs/techniques/super-resolution-interpolation.md#shading-language-and-api-requirements

[sacb0y]

@Ryiah

There is at least one implementation of FSR 3 running on Android (Vulkan), iOS (Metal) and Switch.

https://discussions.unity.com/t/899179

So it’s doable it just isn’t officially supported by AMD, but then AMD doesn’t officially support anything but DX12 which is clearly incorrect seeing that it’s running on more than Windows and Xbox.

https://github.com/GPUOpen-LibrariesAndSDKs/FidelityFX-SDK/blob/fsr3-v3.0.3/docs/techniques/super-resolution-interpolation.md#shading-language-and-api-requirements

From what I’m aware it wasn’t just incompatibility but also performance benefit being zero or worse due to architecture differences. I’d be curious to see if anyone has benchmarked this.

[Edy]

I thought I was experiencing serious issues and annoyances with the current SRP fragmentation and was happy thinking about proper SRP coexistence. But the more I learn about the current situation, the more I believe that throwing everything away and starting over is the most realistic and scalable solution to get out of the hole Unity has been digging themselves into for the past 6 years. I’m starting to understand that the “multiple SRP coexistence” feature will become just another temporary patch, adding even more complexity to the whole mess.

Some quotes that I believe best describe it:

@tatoforever

Btw, I’ve been working with UE5 sources, more specifically with the graphics module, for a year and the benefits of a single scalable pipeline outweighs absolute anything else. Not just for project developers but also engine developers.
Single graphics module, one set of foundational APIs to write rendergraph data/passes, etc. UE graphics module it’s a monster (because of it’s rich set of rendering and graphics features) but it’s a single monster to deal with.

@tatoforever

And this is just a set of problems that multiple pipelines brings. There’s many others at different levels.

@tatoforever

Yeah, we need a single pipeline that scales top to bottom.

@BOXOPHOBIC

this thread is about coexistence, which should not exist in the first place if we had a proper render pipeline.

@tatoforever

The thing i also don’t get is “why not implement a new pipeline that scales top to bottom” in Unity 6?
The same way Unreal Engine do? Eg: disable/enable render passes/features if platform support it or if enabled in graphics settings and use one unit measure for all lights. Finally, provide migration tools from existing pipelines.
This fragmentation can’t keep going on forever. Both HDRP and URP will keep growing and getting more complex. The more you wait the harder will be to have a single pipeline.

Exactly. We all (game devs, AS publishers, Unity devs) just need a single graphic pipeline that scales top to bottom. That’s the only solution I believe can fix the Unity graphics mess and be sustainable in complexity, time, and features.

We’ve been in this hell for 6 years already. At this point, I wouldn’t mind waiting another 2-3 years if Unity focuses all its graphics development resources on developing a proper render pipeline from the ground up and, in Unity 7, makes it the default (unique), deprecates (removes) all others, and provides migration tools and guidelines.

Not only Unreal, but for example, the way Flax Engine handles its graphics engine—a single pipeline where each feature may be enabled or disabled targeting mobile or desktop platforms—is a proper sustainable model Unity should follow.

Want to keep some HDRP stuff around? Fine. Make it completely separate and disjoint from Unity, even as an Asset Store package, with its own set of cameras, lights, units, reflection probes, volumes, etc. Follow the model of the nice coexistence of the two physics game engines (2D and 3D) we’ve had for over 15 years without a single issue. It’s not that the Rigidbody component must be compatible with both 2D and 3D engines, but we have separate and disjoint components for each one. You’re proposing to have Scene_URP and Scene_HDRP anyway, so why not separate everything in such a way that stuff from HDRP cannot contaminate or drive the Unity graphics development decisions? Just consume the SRP API, as any other RP would do. Anyone using this would face their own issues, as with any AS package.

[sacb0y]

@Edy

Want to keep some HDRP stuff around? Fine. Make it completely separate and disjoint from Unity, even as an Asset Store package, with its own set of cameras, lights, units, reflection probes, volumes, etc.

People keep saying this but also don’t think just focusing on URP is an option and I don’t understand it. Package or asset store package what’s the difference? Mindshare?

People want URP to just be Birp 2, and it could be, right now. And even if they focus on a new single pipeline that’s 2-3 years of api changes anyway, and probably api changes beyond that. A birp2 wouldn’t have 5 years of little change, it would be more of the same currently, just without a second pipeline.

In roughly two years and a lot of company turmoil they’ve still managed unify something originally made by separate teams enough that the two pipelines can more or less reasonably be used in the same project. I don’t see a reason to undo that progress for a whole new thing that won’t change the current complaints.

@Edy

You’re proposing to have Scene_URP and Scene_HDRP anyway, so why not separate everything in such a way that stuff from HDRP cannot contaminate or drive the Unity graphics development decisions?

I think people are misunderstanding this is the current state not the permanent solution. And the reasons why things are like this are obvious.

For one URP has an entirely different lighting and exposure model than hdrp it’s more like birp, that alone makes using the same scene impossible.

We need that to come to URP, but once that happens people still tied to birp for this long will have an even bigger hurdle to cross. Hell even current URP users will have a hurdle.

And they NEED to do this transition, just about everything else has a model more similar to HDRP.

Then besides all that water and sky isn’t URP compatible and the amount of water and sky assets that remain incompatible with mobile and WebGL make it clear this is a challenge on its own. As far as I’m aware there’s no native Birp feature that doesn’t work on all platforms (performance be damned). So even a single pipeline would be the same, it’s a limit.

This whole two scene thing obviously isn’t a primary solution, it’s just the current state if someone needs/wants to do it right now and it also highlights the problems of doing so.

[kripto289]

@sacb0y

People keep saying this but also don’t think just focusing on URP

Why urp?
Because there are more users? No.
Maybe because it’s most stable and documented pipeline? No
Maybe because less bugs?
No

Maybe because it has all the functionality, for example fsr2, dlss, ssr reflection, ssgi etc? No.
Maybe because you have already chosen URP and therefore everyone should your choose? Looks like

[sacb0y]

@kripto289

Why urp?
Because there are more users? No.
Maybe because it’s most stable and documented pipeline? No
Maybe because less bugs?
No

Maybe because it has all the functionality, for example fsr2, dlss, ssr reflection, ssgi etc? No.
Maybe because you have already chosen URP and therefore everyone should your choose? Looks like

I’ve already said if I had my choice I would be an HDRP user, but I can’t since I need mobile. I have no particular bias to either. I vastly prefer the HDRP setup over URP.

My point is, if you want a BIRP2, URP is the closest to that, but even if that was the only pipeline that wouldn’t solve all your problems. Moving from BIRP to URP was easy, moving from BIRP to HDRP is not cause so much is different. Thats why people often say “port HDRP stuff to URP and be done with it” cause they expect it to work like BIRP cause URP is like BIRP.

But I think that’s very counter intuitive, I want URP to be more like HDRP so that moving to HDRP or back is easier. But also cause HDRP just has a better lighting setup.

[Slashbot64]

Unity shot itself when the declared URP to be all around BIRP sorta pipeline… I use Voxelplay2 and it only works on BIRP/URP, people start putting there time and development into things like that… And HDRP not being able to scale down more is disappointing… both pipelines are a fail compared to BIRP given the shear amount of problems both have or give, because of its ever changing API and the hindrance that has for every dev asset who has built anything on it. And given the years of development that hasn’t gone into BIRP while URP stays behind HDRP in priority and features…it’s all terrible really.

Anyway OP’s post is more info than I’d ever want to know about the mess of differences between both of them… I’m surprised this topic picked up I thought everyone was just going to leave it alone literally days between OP’s post and when the replies started trickling in lol… I also think mobile getting better anyway, how many years before we just get back to single pipeline that scales and imported assets that just work without this absolute madness that has been created with material conversions and myriad graphic/quality post processing scriptable pipeline inspector views to have to go through… as for URP not supporting proper physical lighting values

We’ve been in this hell for 6 years already. At this point, I wouldn’t mind waiting another 2-3 years if Unity focuses all its graphics development resources on developing a proper render pipeline from the ground up and, in Unity 7, makes it the default, deprecates all others, and provides migration tools and guidelines.

Not only Unreal, but for example, the way Flax Engine handles its graphics engine—a single pipeline where each feature may be enabled or disabled targeting mobile or desktop platforms—is a proper sustainable model Unity should follow.

yes

But I think that’s very counter intuitive, I want URP to be more like HDRP so that moving to HDRP or back is easier. But also cause HDRP just has a better lighting setup.

also yes

[kripto289]

@sacb0y

My point is, if you want a BIRP2, URP is the closest to that, but even if that was the only pipeline that wouldn’t solve all your problems. Moving from BIRP to URP was easy

URP design (code/rendering/GUI/behaviour) so stupid.
For example you need to add render feature in editor for each(!) custom posteffect. For example if your game use 100+ VFX with different posteffects (like black hole/space warp/etc) you need to add 100+ render feature in editor. WTF?
Or lighting rendering in shaders.
How do you think what this code do?

#if USE_FORWARD_PLUS
    for (uint lightIndex = 0; lightIndex < min(URP_FP_DIRECTIONAL_LIGHTS_COUNT, MAX_VISIBLE_LIGHTS); lightIndex++)

URP_FP_DIRECTIONAL_LIGHTS_COUNT means point lights, so obvious
Do you thinks it’s forward plus code? No.
Because forward+ code is here

LIGHT_LOOP_BEGIN(pixelLightCount)
LIGHT_LOOP_END
............
    #if USE_FORWARD_PLUS
        #define LIGHT_LOOP_BEGIN(lightCount) { \
        uint lightIndex; \
        ClusterIterator _urp_internal_clusterIterator = ClusterInit(inputData.normalizedScreenSpaceUV, inputData.positionWS, 0); \
        [loop] while (ClusterNext(_urp_internal_clusterIterator, lightIndex)) { \
            lightIndex += URP_FP_DIRECTIONAL_LIGHTS_COUNT; \
            FORWARD_PLUS_SUBTRACTIVE_LIGHT_CHECK
        #define LIGHT_LOOP_END } }
    #else
        #define LIGHT_LOOP_BEGIN(lightCount) \
        for (uint lightIndex = 0u; lightIndex < lightCount; ++lightIndex) {
        #define LIGHT_LOOP_END }
    #endif

Using URP and opaque/depth buffer is a pain. You can see this image in the previous post: https://discussions.unity.com/t/948251 page-2#post-9883905.

URP render feature code is so poorly designed. You can’t just use CoreUtils.SetRenderTarget like in BIRP/HDRP rendering. You must use “ConfigureTarget” and “ConfigureClear,” or the rendering will be broken. Anyway, it can be broken for any reason in the editor or game view.

HDRP rendering has even more problems. URP and HDRP are not BIRP2; they are ugly and unstable deprecated code that is constantly being refactored.
It feels like the urp/hdrp teams were writing code for the engine for the first time and had never seen game engines and games before.

[kripto289]

@Slashbot64

I’m surprised this topic picked up I thought everyone was just going to leave it alone literally days between

In fact, this thread inactive: most developers are already tired of this mess, and there is no hope for changes. No one wants to comment on anything anymore because all this has been discussed for the last 5 years without any result.

Do you think management will draw conclusions? No, it will continue to hire (or fire?) even more employees, and in 10 years, there will be 2 separate engines and 20% of the market (because the rest went to Godot/UE due to the lack of Unity development). Can anyone name any significant unity changes over the last 5 years? Maybe nanite/lumen analogs? Maybe virtual shadows and SDF? Oh, right, the introduction of shadows from point lights and TAA in 2022 lol.
New GPU resident driver? It’s just the another replacement feature, instead of static, dynamic batching, instancing, BatchRendererGroup and SRP batcher.
STP it’s just the simple temporal reprojection (it’s been used everywhere for the last 5 years+)
The last chance is the new one pipeline, taking into account all the mistakes. Unity has no credibility left, unfortunately

[sacb0y]

@kripto289

For example you need to add render feature in editor for each(!) custom posteffect. For example if your game use 100+ VFX with different posteffects (like black hole/space warp/etc) you need to add 100+ render feature in editor. WTF?

Imma be honest, as someone who develops on multiple platforms I love the render feature setup. It simplifies a good deal that was complex before to manage across multiple platforms.

I know asset store devs don’t like it (see a few just try to lump everything in a single render feature), but I like it. Cause I know what each platform is actually using.

@kripto289

URP render feature code is so poorly designed. You can’t just use CoreUtils.SetRenderTarget like in BIRP/HDRP rendering. You must use “ConfigureTarget” and “ConfigureClear,” or the rendering will be broken. Anyway, it can be broken for any reason in the editor or game view.

HDRP rendering has even more problems. URP and HDRP are not BIRP2; they are ugly and unstable deprecated code that is constantly being refactored.
It feels like the urp/hdrp teams were writing code for the engine for the first time and had never seen game engines and games before.

And you think one whole new pipeline would fix these problems or just create more of them?

It honestly just sounds like a grass greener mentality. When in reality the same issues would repeat.

[tatoforever]

@sacb0y

And you think one whole new pipeline would fix these problems or just create more of them?

This whole tread exist because of the problems fragmentation created in the first place. Don’t you think tackling the problem at the very root will fix it? Keeping Unity fragmented will only worse the current situation even more.
In any case, unifying pipelines or creating a new one will force people to do drastic changes in their graphic code but the ideal situation is one pipeline that scales top to bottom.
In fact, we didn’t needed neither HDRP or URP in the first place. People asked for more flexibility in the graphics pipeline, not for full source code or new renderers.
The parts in BIRP that we needed access was existing deferred and forward renderers passes but it wasn’t possible for who knows/whatever reasons; they decided that SRP will fix the initial problem (of more flexibility in the graphics pipeline) and here we are today.
I have yet to come to a project where you need to change existing pipeline’s code. Most people need to add renderpasses, not to change existing ones. So the whole idea of creating your own pipeline is pointless, even though you don’t have full control of it (eg: culling), but that’s subject for another thread.
Fast forward to 2024, three completely different pipelines, equally used and distributed across existing projects and users and no one has any idea when the fragmentation issues will stop.

[kripto289]

@sacb0y

Cause I know what each platform is actually using.

Why? Can you give any example where you can’t find out what post-effects you have on your screen right now?
Post-effects can be determined visually. There is no need to create a complex “render feature” system for this.
Also you can check profiler/debugger/renderdoc to find all posteffects =/

@sacb0y

nd you think one whole new pipeline would fix these problems or just create more of them?

It honestly just sounds like a grass greener mentality. When in reality the same issues would repeat.

I don’t think anything will change, and the fact that there hasn’t been a single comment from Unity staff in a few weeks confirms my theory. I am sure that some developers also understand that there is no way out here, but they cannot reach management.
You don’t have to worry. URP will be here for the next 5+ years, until Unity writes a post about bankruptcy one day due to a series of unsuccessful decisions

[sacb0y]

@tatoforever

In any case, unifying pipelines or creating a new one will force people to do drastic changes in their graphic code.

Exactly, the solution is already happening but people will be annoyed further by the additional changes. Even if they simply started over and made a new pipeline nothing would change on that front.

@tatoforever

All this could’ve been avoided.

Agreed, the flaw was the pipelines being made by entirely separate teams with entirely separate goals when it didn’t need to be.

@tatoforever

So the whole idea of creating your own pipeline is pointless, even though you don’t have full control of it (eg: culling), but that’s subject for another thread.

I don’t think the pipelines ever needed to be entirely different as they are now that was a flaw in conception. But it’s clear some tools simply aren’t viable on some platforms. I think a clear line is better. We already have enough shader compile issues.

I don’t agree the “just turn it off” solution is better. When I use URP, much like Built-in, out of the box I can use all the features there and know it works for the platforms I need. When/if I use HDRP I know I’m using features less broadly available. Especially when tech is entirely new let alone performant. Mesh shaders for example as far as I know has no mobile equivalent, along with a hard cut off of GPU support. Doesn’t make sense for URP.

It’s kind of like how people praised some games on PS5/PC that were originally PS4 games at least at some point, now when we’re getting to games made exclusively for PS5 and now there’s problems all over the place.

When I see people complain “Why isn’t HDRP as optimized as URP” I think they miss the point. When those features get optimized and compatible they’ll come to URP.

I like that mentality.

To me we don’t have three pipelines, we have two pipelines and a legacy pipeline for compatibility. And people are making a concentrated effort to keep that legacy pipeline around. As such, there’s not enough pressure to improve. We have the Unity dev’s trying to figure out how to appease built-in users (probably delaying Block Shaders further) so they will fucking use URP/HDRP but also stop using/supporting BIRP so they can depreciate it. Maybe that’s why URP still doesn’t have realistic light values. Maybe unity is terrified built-in users or asset store developers will riot.

I say fuck it.

@kripto289

Post-effects can be determined visually. There is no need to create a complex “render feature” system for this.
Also you can check profiler/debugger/renderdoc to find all posteffects =/

I’m gonna disagree on the “visually”.

And how can I guarantee it’s not included in the build? How do I know the asset store developer made things properly so even if a feature is turned off it’s not included anyway?

I have this problem with beautify where all the features are in a single render feature and they have some auto-stripping thing but sometimes it just doesn’t work for no reason causing massive build times.

I had similar issues before switching to URP.

EDIT: Also like, you can’t tell me checking render doc and stuff is somehow easier than a simple render feature list. You can argue it’s better but it’s not remotely easier, I don’t even think those work without switching platforms and such.

@kripto289

I don’t think anything will change, and the fact that there hasn’t been a single comment from Unity staff in a few weeks confirms my theory.

it confirms nothing, they’re terrified of communicating with anyone at the moment.

[AljoshaD]

@kripto289

I don’t think anything will change, and the fact that there hasn’t been a single comment from Unity staff in a few weeks confirms my theory.

@sacb0y

it confirms nothing, they’re terrified of communicating with anyone at the moment.

Nono, we’re just busy working on this as we speak But appreciate the discussion here.

@tatoforever

I have yet to come to a project where you need to change existing pipeline’s code. Most people need to add renderpasses, not to change existing ones. So the whole idea of creating your own pipeline is pointless, even though you don’t have full control of it (eg: culling), but that’s subject for another thread.

We see many examples of projects that change the existing pipeline’s code, even some that write a whole pipeline from scratch. But some of these have done this because they did not have the right extension APIs. With the URP RenderGraph work, we set out to improve extensibility even more to reduce the need to fork URP. There are still use cases though.

I’ll get back to this thread later.

[impheris]

@kripto289

Oh, right, the introduction of shadows from point lights and TAA in 2022 lol.

(for indie artist like me) a water system that kind of works at least for basic stuffs and some volumetric cool things imo are kind of useful for basic stuffs, tbh yeah everybody knows that unity has been stagnant for many years, that is not a secret.

@sacb0y

I say F*** it.

yeah move on XD

@sacb0y

And how can I guarantee it’s not included in the build?

exactly and that happened to me too

@AljoshaD

Nono, we’re just busy working on this as we speak But appreciate the discussion here.

i hope you are taking notes becasue this discussion and problems has been around for years with almost no useful changes…

[Onigiri]

People assuming it’s possible to unite two render pipelines together and scale from low mobile to high end PC. Is there any examples of this in other engines? As far as I remember half of features of UE doesn’t work on mobile. One of the coolest things of HDRP is that no matter what renderer you choose(forward or deferred) everything just works. I don’t think this philosophy could be implemented with one scalable pipeline.

[AdrielCodeops]

@Onigiri

People assuming it’s possible to unite two render pipelines together and scale from low mobile to high end PC. Is there any examples of this in other engines? As far as I remember half of features of UE doesn’t work on mobile. One of the coolest things of HDRP is that no matter what renderer you choose(forward or deferred) everything just works. I don’t think this philosophy could be implemented with one scalable pipeline.

Suppose I want to render a body of water in URP? I can’t… Well, let’s try rendering some clouds in URP… I can’t.

What exactly is the difference between this and a warning telling you that this water/clouds/antialiasing/raytracing system/probe system is not compatible with X platforms versus having to almost recreate my project in another pipeline to make it work?

Do you really think locking yourselves into a feature set/platform is a good thing just because you might make a mistake and turn on volumetric clouds on mobile? And you won’t notice?

If we were just talking about some advanced stuff like raytracing, then I might agree… But this is not the case.