Resolved A postmortem

Hi Jason,

Thanks for your question. I’m the engineering director of the newly formed Render Pipeline group. I joined the SRP effort roughly a year ago. In hindsight, there are a number of things we would have done differently from the start. This might seem obvious now but there were many factors involved in these decisions and it will certainly not have been so straightforward.

Packages
When starting the SRPs, “packages” was a new concept that gave the opportunity to develop code on top of the core engine without hitting the issues of working in the main Unity repo on a monolithic code stack. The Graphics packages were a first big adopter of packages and of course hit all the issues with a new paradigm and (uncomplete) package tool set. In hindsight, both the package tooling and the general graphics stack were not ready to work efficiently on this. The lower level graphics stack needs to evolve in lockstep with the SRPs giving us little advantage of a decoupled life cycle. And we had all the overhead of managing packages. We solved that by converting the Graphics packages to Core packages that are bundled with the editor and developed in lockstep. We recently switched the development process to working directly on the monorepo that contains the entire graphics stack. This allows us to more efficiently test and develop, and avoid the separate package release overhead. While we keep the benefits of packages, being visible and modifiable as C# source. All this change took a lot of effort that could have been avoided.

Separate pipelines with isolated teams
The original vision and assumptions were different from what we have now. Originally, HDRP and LWRP (Lightweight Render Pipeline, URP’s ancestor) were each specialized for a sub-set of devices (low-end/mobile for high-end/console) without overlap. The engineering effort also started in different organizations, where HDRP grew out of research and was very future focused. With the development happening in separate teams with a completely different focus, the end result is of course that the pipelines code and workflows diverge in places where they should be similar. We have recently formed the Render Pipelines group and brought all the Render Pipeline teams together in 1 group under 1 director. We have the URP, HDRP and RP Core team. The RP Core team is now focused on unifying the workflows and the code base. Also, with more unification our teams can develop and test more efficiently for higher developer velocity. We have set up a process to design features holistically for all platforms (from very low end to very high end) and for both pipelines from the start. Features might still land first in one pipeline but less rework is required to scale them to another pipeline. We have grown the number of experts on mobile and XR significantly in our group last year to be able to deliver features across all platforms at once. The main focus of those experts this year is finishing functional parity of URP with Built-in so the effect of this will become visible after this.

Asset compatibility between pipelines
This builds on the previous point. Assets like shaders and materials should have had a basic level of compatibility from the start. Obviously, the render pipelines will have different features and capabilities but a basic lit material for example would be helpful for many asset store providers. Transitioning the asset store from Built-in to the Scriptable Render Pipelines would be less time consuming for asset store developers. In the vision of deeply specialized render pipelines this puts some constraints on the RP designs but overall, it is required for a more productive and healthy ecosystem. With the Shader Block work progressing well, and the work on the cross pipeline shader graph, we will have a compatible shader and material soon. And with URP getting to functional parity, Built-in RP should finally be on its way out so asset providers can focus their efforts on SRP. Additionally we will continue to increase asset compatibility to productively support both URP and HDRP or use both for your project.

Production Ready
This one is debatable because many users have released successful games with the SRP that they could not have done with Built-in RP. But the SRPs were declared production ready quite early which added a lot of extra work for the teams to try to make the big changes the SRPs needed while trying to avoid complexity and work to upgrade a project for our users. This obviously was nearly impossible and apart from slowing the development down it created a headache for our users. We are now very careful with the next step of changing the default render pipeline from Built-in RP to URP (or SRP). We first want to make sure we have full functionality parity, high robustness and overall quality, and better performance across all platforms before driving more users to the SRPs. That said, as you can read in the blogpost we are getting really close and many projects have everything they need to benefit from using the SRPs with the latest releases.

DOTS
Soon after the SRPs started DOTS became a big thing at Unity. A lot of time went into figuring out how to support the DOTS effort and it fragmented the efforts in Graphics. In hindsight, it would have been more efficient to focus first on completing the SRPs to the point that they are a better alternative than Built-in for all projects, and then move our focus to DOTS for optimization. On the other hand, DOTS will allow us to increase performance so it’s important to integrate that work. How to balance these priorities has not been straightforward since we have wildly different users. Our priority now is clearly to first complete the SRPs. To be clear, ECS is also still important and great progress is being made with ECS as well. In graphics for GameObjects, we now have a clear vision on how to apply burst and jobs extensively to optimize performance. The BatchedRenderGroup was a direct result of that work and is now a key component for significant performance improvements.

 

That is definitely what the points mentioned above aim to solve. I focused on answering the question "what would we have done differently". I fully understand the complexity with choosing a render pipeline currently. The points I raised could potentially have allowed us to complete the SRPs significantly faster. Which would have addressed your concern. I mentioned the production ready tag because that did not serve anyone indeed. We are now laser focused on functional parity with Built-in to remove a lot of this complexity. You’ll still need to choose between URP and HDRP but that should be more straightforward based on your platform needs. And the Coexistence work and increasing compatibility will help you migrate your project if you really need to between those. While we’re still maintaining Built-in RP we haven’t added any new features indeed. The problem with doing that is that we would slow down SRP development. That could have been acceptable if we completed the SRPs earlier.