TL;DW:
*It is not known what Unity will be called after 6. They talk about “next generation” but don’t assign a number. This could mean branding is not finalized. Or if we’re less generous, perhaps they’re not comitting to a specific release.
Sh*t yeah 
I mean, sounds good? But one of the most important reasons for SRPs was that those were 2 fundamentally different rendering stacks targeting very specific use cases. If this goes the way BiRP was, then I fear that it’ll step into the same pitfalls, where necessity to support low-end will not allow high-end to shine with its specific solutions, and vise-versa, overall design that has to support high-end stuff will not allow some low-end solutions to perform optimally, or at all.
More info needed, I currently find it questionable (but good job on unifiying the workflow, I suppose?).
Needless change. Not hyped at all.
I’m sure they’re still aware of those core issues. Godot has the same base for multiple render pipelines but can switch at any time between Compatibility/performance oriented OpenGL and high-end Vulkan implementations. Best of both worlds.
From my POV i would prefer solid SRP co-existence. Unified is screaming problems for me (Shader variant hell in 3…2…)
Same thing as in Unreal as well, which allows you to select different core backends for rendering. Wouldn’t mind that at all, really. Just definitely not as BiRP did by clumping literally everything into one place.
The new unified renderer sounds cool, but I have some worries. If it gets too complicated like BiRP, it might not work well for both low-end and high-end users. I hope Unity can balance the needs of all systems. Looking forward to more info.
Roadmap video is released, I updated the OP. It’s not a new renderer but a URP+HDRP refactor with a common base.
It is more nuanced than that though, this whole segment was wrapped in very clear language than none of it is guaranteed to be in the actual next version, regardless of what it is called, just what they are working on.
However they then go on to say that BiRP is depreciated in Unity 6 and to be removed in ‘next’ version, but the solution to that and having a ‘unified’ Renderer is also in A ‘next’ version, but they give NO GUARANTEE that these events will happen in the same ‘Next’ generation version!
This is either really bad communication ( its UT so that is almost a given these days ) or is going to be an absolute clusterfuck!
The blindingly obvious approach that should be taken is to ONLY depreciated BIRP once the new coming soon ‘we promise’ Unified Renderer is fully supported in a ‘next gen’ version. It should then only be removed completely once the Unified Renderer is clearly at feature parity.
But this is Unity - so of course I fully expect Unified Renderer to be unfinished and not at feature parity, especially since as far as I can tell the unified Renderer is simply unifying data so that it can be shared/used between URP or HDRP! The problem is every time I dig into URP or HDRP, I inevitably come across a situation or forum post that shows they are not at feature parity with BiRP.
So in summary, i’m very happy Unity is committing to unifying URP & HDRP, doing it via sharing of data seems to be a sensible solution - though I don’t think they addressed how that applies to materials and shaders - so thats a potential BIG stumbling block. I am however very apprehensive to the EARLY commitment to removing BiRP! Depreciated it by all means, but do not have a fixed timeline to remove it until the Unified Renderer has been proven to allow for a relatively seamless transition.
Edit: I’m also not a fan of dropping BiRP as in recent tests using a complex Synty Demo scene it was still faster than URP in Deferred rendering. For Forward URP was impressively better than BiRP, but the 10-15% drop for Deferred is not good. Sure some of these new systems like GPU Resident drawer might improve that, but my issue here is that by default URP is meant to be at least as efficient than BiRP, yet it isn’t!
They had a recorded demo of the actual editor swapping between different renderer settings, which looked rough around the edges but functional. And unification of URP and HDRP is not new, they’ve been at it for a year or two already.
Again, unified renderer is not new technology, just a refactor of SRP. There’s no reason why it wouldn’t be there for the next version. And per their data, the vast majority of newly released games are SRP based. Also, consider release times. They’ve ditched the yearly release model, so Unity 7 LTS is at least two years away. Plenty of time to deliver on what they are promising.
I dunno, seemed pretty clear to me.
I think that ship has sailed. Can’t drag the BiRP corpse around for another decade. I also don’t quite get what feature parity with BiRP really means when global hit games have been shipped with SRPs just fine.
Here are two examples I randomly came across in the last day
https://www.reddit.com/r/Unity3D/comments/1fjwea2/hdrp_proper_fps_camera_still_impossible/
Cannot say for definite that both of these are impossible to achive or if its just a question of finding the right way to use some new feature or SRP, but the fact that neither have provided a solution that works for the OP in such a way to replicate the BiRP method is concerning to me.
My concern is that both URP and HDRP design decisions have effectively removed options that used to be available to developers, resulting in far more constrained rigid rendering systems that ultimately adversely affect inspiration and new rendering techniques.
Another example is that neither URP or HDRP would allow you to build a Portal like game today as both use the stencil buffer in such a way to make it impossible to use for your own means ( maybe URP forward might work I’d need to have another look, but pretty sure forward+ wont )
Min 24:30 really got my attention. I would love to finally be able to use Block Shaders (they announced them like 2yr ago). I’ve always been hating shadergraph-related workflow when trying to maintain complex shaders that mix-match ShaderGraph & HLSL. It was always too hacky, but this seems like a real step forward
Don’t think of it as a new pipeline, think of it as making URP and HDRP seamless.
Yeah i agree this is a concern but they’ve been improving the variant issue, and also much of it would come down to separating graphics features.
Like the way it works in URP now can keep variants low.
You can see here how drastically things get cut down.
Issues like this is why feedback on the render graph thread is important. We’ve had half a year of preview to make sure they’re aware of issues like this rather than ignoring it and trying to keep birp around 
EDIT: That said the way this thread reads it sounds like a perfectly solvable solution (i’ve done something similar but on URP) they just can’t do it the way they used to.
Wait, it can’t be both?
Frankly i’ve posted too fast. As actually Unified seems to be precisely “solid SRP coexistence”. I certainly like what i`ve seen up to this point.
A good idea on paper and something majority of studios have been asking for since they started trying out URP and HDRP then running into the pitfalls. The selling point will be in the execution; they can’t really mess that up at all. Id be hesitant to commit a production to a unified renderer until its been through the ringer for probably a year by other studios and core new-feature issues are fixed.
I do think removing BIRP before URP is even feature parity is a big mistake. Our project at work is on 2022 BIRP simply because we can’t use HDRP (Have to ship to Switch, mobile and mid/low PCs) and URP has worse performance and much longer build times whenever we switch to it to evaluate.
It’s not clear but I doubt that the Unified Renderer will be simply URP + HDRP. Or 100% compatible with either of those. For three reasons they will be using.
1: OpenPBR
2: Shader graph 2.
3: Block shaders with a shared representation with Shader graph 2
The Unified Renderer looks like a great improvement, but I don’t expect it to be pain free.
Why would conforming to OpenPBR not be compatible with the current URP / HDRP renderers?
As i understand, the standard proposes common rendering approaches for materials. As well as common labeling & defaults & overall naming of fundamental shading concepts and its implementations.
I dont think this necesarrily breaks URP + HDRP. It would certainly require a restructure of the lighting libraries, but not necesarilly be breaking any fundamental SRP approach. It’s just tweaking (although deep tweaking) of how values affect some shading output.
It will probably mostly affect how the Standard lit shaders work. But will probably have 0 implications for any Unlit / CustomEffect / RendererFeatures (now graph) etc approach.
The same goes for ShaderGraph2 / BlockShaders, these are just authoring frameworks to produce the shader source. There are currently some BlockShader-like approach in some custom asset-store tools that are quite impressive, but still compatible with the overall SRP approach.
Again im probably being naive, and yes i dont buy that it would be fully “painless”. But i dont see incompatibility issues of any kind
We don’t even know yet if you can load a ShaderGraph 1 shader into ShaderGraph 2. Even if you can likely you will get different output.
