Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Join us on Dec 8, 2022, between 7 am & 7 pm EST, in the DOTS Dev Blitz Day 2022 - Q&A forum, Discord, and Unity3D Subreddit to learn more about DOTS directly from the Unity Developers.
    Dismiss Notice
  3. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Resolved A postmortem

Discussion in 'SRP Dev Blitz Day 2022 - Q&A' started by jbooth, Sep 28, 2022.

  1. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,344
    From the audience, there's always been a projected attitude from Unity that the SRPs have all gone as planned and there aren't any real problems with them. But anyone who's used them or I expect worked on them knows that's not the case. I'd love to see a postmortem of what Unity considers to the mistakes made in the process- it's no doubt that introducing new render pipelines was going to be a bumpy experience, but if done over, what would be done different?
     
  2. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    123
    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.
     
  3. LaireonGames

    LaireonGames

    Joined:
    Nov 16, 2013
    Posts:
    668
    Its a bit annoying to hear that something that isn't listed here as a regret is what SRP has meant for the state of graphics within Unity.

    To be clear what I mean is that whilst all of this mess has been happening with SRP, Built In was basically abandoned as soon as Unity claimed SRP where 'production ready' despite it being years later and they Still don't have feature parity.

    This left those of us that knew better with a horrible choice. New SRPs that are still heavily in progress or stay on something that works but that is now unsupported.

    If this was me a big hindsight fix would be to have supported Built In for longer whilst labelling the SRP for what they where, experimental. To be honest this is where a lot of my frustration lies with Unity because it felt like they tried to force users to adopt SRP.
     
    Last edited: Sep 29, 2022
    jeromeWork likes this.
  4. AljoshaD

    AljoshaD

    Unity Technologies

    Joined:
    May 27, 2019
    Posts:
    123
    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.
     
    LaireonGames likes this.
  5. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    1,528
  6. jbooth

    jbooth

    Joined:
    Jan 6, 2014
    Posts:
    5,344
    @AljoshaD Thanks for the writeup! It's always interesting to hear the other side of the coin- I would not have guessed that packages were such a big time suck, for instance.

    I mean LWRP was abandoned about a week after it was announced as production ready. I think Unity going public and its marketing team wanting to promote the latest tech did a huge disservice to the community, pushing people to start projects on a pipeline that even the Unity team knew wasn't ready.

    To me, the largest loss on "the state of graphics" in Unity is the sheer time suck of managing multiple pipelines. Features were being coded multiple times in slightly different ways, lots of duplicate effort that basically just made everything more confusing for users, and features in one pipeline that could just as easily be in both. And for people like myself, Unity basically dropped a man year of janitorial work without pay with the alternative being going out of business.