Join us for #SRPLife Week!

Over the last few years, Unity has introduced the Scriptable Render Pipeline (SRP) system, along with several render pipelines (LWRP/URP, HDRP). These new render pipelines have created significant issues for Unity users and publishers on the asset store. A few with examples are listed below:

  • Shaders must be rewritten from the ground up for each pipeline. There is no upgrade path from Standard to an SRP, and shaders written for one SRP (URP) won't work for another(HDRP).
  • No upgrade path for shaders between versions of the SRP. URP 7.1.8 shaders are not compatible with URP 7.2.1 shaders, yet are both for Unity 2019.3.

  • Rendering code must be re-written for each pipeline. The CustomPass system for URP and HDRP are completely different, yet do the same thing.

  • Code is often broken or different for no reason on different pipelines. Camera.backgroundColor is used in URP/Standard, but in HDRP it's stored in a different property on a custom component and aliased in the editor to look like the camera component is being used.

  • No documentation for shaders. This means countless hours reverse engineering the shading system. And when things change, there is no documentation on what has changed.

  • New versions not sync'd to Unity releases. URP 7.1.8 and URP 7.2.1 shaders are incompatible, and both for Unity 2019.3. Users are forced to upgrade depending on which patch version of Unity 2019.3 they are using, making it impossible to support.

  • Assets written for multiple pipelines cannot "just work" when installed. If you have even the simplest material, users will need to manually upgrade your project to work in SRPs.

Since SRPs were conceived, we have been asking Unity to address these types of issues, and this has fallen on deaf ears. Even after several years, we have no official response to any of these issues, or even confirmation that Unity see's them as actual issues worth solving. I have also personally received the feedback from several Unity employee's that "Only you care about this stuff", which I know is not the case.

As such, we invite you to join us in changing your profile picture from to the following image to raise awareness of these issues, and show Unity that more than one person would like to see them addressed.


I generally like the idea that Unity reinvents itself to keep up with new technologies and to optimize their pipeline from the ground up. And i really hope that some day (IN THE NEAR FUTURE) universal renderpipeline will be my new daily workhorse.
But for now i have to agree with you, there is too much half-finished stuff going on at the same time. These days everything seams so "agile" that it actually feels like chaos.
HDRP sometimes feels like an impulsive response to Unreal's AAA trailers and the stuff we really love and prefer unity for is slow and unconsistent in developement.
When i first heard about SRP i thought it meant a seamless transition from LWRP, over BIRP to HDRP ... but it's actually 3 independent engines now, that you can modify in their own ways!?
And get this damn package manager tidied up... I can't believe something so essential like the renderpipeline is sitting right between a "google AR ios plugin" and an in-app "purchasing system"


I agree with everything said here, hopefully they realise it's a bigger issue that is experienced by more than just a few people. Just because not everyone speaks up about the issues on the forums, doesn't mean they don't have to go through the same problems.


Done. I agree 100%. As excited as I am for all the SRP content, my only option has been to completely avoid it until it's finished.


Ya I agree , I use many other engines over the years (Still do ) when I first seen the new rendering, I knew it would be a mess.....I hate to say this, but its been what Unity continues to do, forget about those actually wanting to release stuff...and others who have... but we won't move to the new rendering, until its actually usable....stable... So I would agree with the OP and Oilli

1 Like

Well i waited for like ~2 years? before i even got into SRP and it's still not production ready imo


That is really infuriating. I don't comment on those threads because I am not a shader programmer and have nothing substantive to contribute -- but the benefits of what you're arguing for are indisputable. And plenty other people do comment on those threads in agreement with you. Truly, what the hell has happened to Unity?


Living the #SRPLife over here too. The documentation is extremely weak.


Well, there would be a lot more still here if they had a fraction of your good will and patience.


While I don't agree that Unity is deaf to these issues (as you well know @jbooth_1 some people are painfully aware), I think in general Unity needs to at least acknowledge them publicly (not through individuals) and lay out a path forward.

Here's some more points.

  • Lost functionality. Things that emerged from 10+ years of graphics development at Unity are suddenly gone. Getting them back means fighting with QA, nagging every Unity person you can find, and insisting that these missing is a bug, not a "feature request you should discuss in the forum". Examples include GPU Mesh Particles (1000x speed regression), 360° Stereo Rendering (omitting an entire industry)
  • Not enough Testing in the Graphics repo. I had to personally create and PR unit tests and entire test categories for the URP where I got told "well, we can't test any combination, can we" for very common usecases (URP + ShaderGraph + VR). This goes hand in hand with the practice of pushing knowingly broken code to master and "fixing it in subsequent PRs" which almost always lead to regressions.
  • Not enough dogfooding. Since URP/HDRP/ShaderGraph are separate packages, they are maintained by separate teams without much communication in the past. This leads to finger pointing ("that's not our fault") and curious cases of URP devs never having used SG, SG devs never having used URP, XR devs not touching Unity (only C++ backend) and so forth. I'm a strong believer that time spent "in the system" is important for everyone and ultimately avoids many errors and saves time.

I do believe the SRPs are the right way forward, and originally were a good idea. Deciding to develop them without a common system architect across graphics features was a bad one.


I like your ideas jbooth. I would also like unified workflow for URP and HDRP, one engine instead of 2 different ones.

I've made this scheme as suggestion how to unify SRP in one modular engine with inspiration of Houdini.
For example, one could create terrain instance running with foliage system and could switch between URP or HDRP for render.

Workflow and graphical interface would be the same for both SRP (shader graph UI , custom processes UI,..) only will they run in background differently.

I've also would like to SRP would become of a single instance engine, instead of installation per project base.


I get the shivers when upgrading from one minor Unity version to the next. Let alone upgrading SRP minor versions. The Horror! The avatar describes best what I get to see. And the nightmare and huge waste of time that follows ahead.

For HDRP I've been thinking for quite some time now that there hasn't been any architecture concept. At all.


I was very impressed with the LWRP Shader Graph system and invested a lot of time in it, only to have almost all of my efforts trashed by the next version that came out.

Even the samples from Unity’s own blog didn’t work from version to version.

This in turn made me avoid the entire system forever. If anything, it shouldn’t have been shown or released until it actually worked properly.


We've been using HDRP for our project, and it was mostly fine so far. However i do have a couple of gripes with it:

1) The custom pass feature. Its great to have, but why the hell are you exposing only 6(!) injection points? Look at how its handled in the standard pipeline Why not expose injection points for each rendering step like that? It literally takes 2 lines of code for each injection point, and it doesnt introduce any performance impact, so whats the matter? Why do we have to embed the package and modify the code manually just to add injection points that we need?

2) Locking most of the code/classes behind access modifiers. I understand that some code isnt designed to be accessed from outside, but some things are absolutely necessary to have access to. For example we use modified version of the HDRP/Lit shader, so we need a modified Editor GUI class as well. But can we inherit from the default LitGUI class that HDRP/Lit shader uses to write our own modification? Nope. And we need the custom editor GUI not just for the quality of life, unity uses shader editors for essential functionality, like setting keywords/stencil values, so we cant just ignore it (which is another problem IMO, editors shouldnt have anything to do with that in this case, it should be controlled with some project-wide controller). Ok, we can write our own shader GUI without inheriting i guess. So we need to do our own stencil setup as well. Ok, let me get the stencil values from the StencilUsage class. Oops, its also inaccessible due to its protection level. Great. That also means that in any custom coded shader we have to manually hardcode stencil values and change them manually with each HDRP upgrade where they decide to change up stencil values. Amazing.

Another example is rendering objects in custom passes. Unity has an example custom pass, which uses this line:
PerObjectData renderConfig = hdCamera.frameSettings.IsEnabled(FrameSettingsField.Shadowmask) ? HDUtils.k_RendererConfigurationBakedLightingWithShadowMask : HDUtils.k_RendererConfigurationBakedLighting;
Try replicating that in your own custom pass, and you'll get a compilation error, HDUtils.k_RendererConfigurationBakedLightingWithShadowMask and HDUtils.k_RendererConfigurationBakedLighting are just not accessible due to their protection levels. Why? Whats the point of doing that?


I don't have experienced yet the transition from a legacy project to the new SRP (Urp or HDRP) so I shouldn't express my opinion but I have faith on experienced devs and what described here is very very far from what I'd like to face when the transition will be unpostponedable.
So, please Unity devs, try to face these issues and give us the best workflow user-friendly tools possible.

1 Like

You are just bad developers and do not know how to work with SRP!
Just a couple of mouse clicks and my 4k render has 222 fps! At the same time, it is possible to achieve maximum optimization, 0 draw 0 vert 0 tris!
If you turn off the shadows, then the frame time will become -1ms and my computer will fly to Mars.
This is only possible with SRP !!!
Graz Unity, you are the best!

Just kidding, SRP is terrible, URP works with a bunch of bugs, there are no shadows, post processing slows down, the shader graph constantly crashes, the build works differently from the editor. This is just hell to develop :(


SRP is excellent. Its just URP are bad... HDRP is fine

I'm working on a game that I'm tempted to switch to URP. The benefit of performance, access to shader graph and vfx graph... sounds great! But, every time I think I'm ready to commit, I run down the features I wanna use and remember why I havent.

Light cookies? Nope.
AO? Nope.
Decals? Nope.

Not to mention the amount of store assets that don't support URP. Many visual effect assets like NGSS and Aura 2. It's too much of a gamble of what your locked into, especially as a solo indie dev who relies on asset packages like these to make games that would otherwise be too complex for one person to finish.

That said, credit to the teams working hard at maturing this tech. I think it has great promise, it just needs to benefit from more cross-team communication and candid acknowledgement of what needs to be shored up to be 'production ready'.

Thanks for raising awareness on this issue. I hope SRP stabilizes in the next year; I'd really like to use it.


I'd suggest keeping the profile images in place until the problems have been suitably addressed.


Had so many problems with URP breaking on version change. Also trying to get into DOTS is a nightmare. Little solid documentation, major differences between HRDP and URP - that has to indicate a design issue!