Resolved Tech behind URP Codebase

I’m Manuele, tech lead of URP. I can talk a bit about the Render Graph work that lays the foundation to address your concern. As you mentioned, one of the first steps to bring the pipelines closer is to adopt the RenderGraph API in URP. The reason why we are tackling this now and not in previous versions, is that this work was dependent on other major overhauls like replacing RenderTargetIdentifiers with RTHandles.


Currently the RenderGraph API used by HDRP is not optimized for mobile TBDR GPUs, since HDRP doesn’t target that hardware, so vital optimizations like load/store actions and Native Render Passes support (which translate to Vulkan RenderPass and Metal Encoders being setup optimally under the hood) are being added as we speak to the Core API, to allow URP to fully take advantage of it on that hardware.


We are very excited to finally be able to add support, because thanks to RenderGraph we will be able to enforce a stricter and safer API for writing RenderFeatures and custom ScriptableRenderPasses and really bring the extensibility and customization potential of URP to the next level. Thanks to the new API we will be able to easily guarantee something that was problematic with the old ScriptableRenderPass API, and we can finally reach our original vision in terms of URP being an “heavy customizable” pipeline:

• Optimized user RenderFeatures/Custom Passes: the current pass API is too permissive and allows users to do something like call cmd.SetRenderTarget not only at pass configuration time, but also in the Execute(). This made it impossible for the URP renderer to figure out ahead what users might do to a pipeline render target in their injected passes. Because of this we had to play it conservatively and always “Store” these targets, since users “might” need them. Thanks to the dependency graph provided by RenderGraph, we will be able to optimize bandwidth more aggressively, since we will always know what the lifetime of a specific RT will be, even when user-injected passes are in the frame. Similar issues would also not allow us to apply NativeRenderPasses and framebuffer fetch optimizations in the past, since it was impossible for us to know the users intentions before time. All these problems should go away in the new system.
  
  
• Extensibility: one of the limitations of the old API was very limited access to URP frame resources (i.e. shadow RTs, GBuffer, Color, Depth, etc). In the new URP RenderGraph path these will all be accessible to users in their custom passes.
  
  
• Extensibility: one of the long term goals would be to expose as much as possible of the “internal” URP passes (DrawObjects, CopyDepth, DepthOnly, etc) and make them reusable in your own custom code.
  
  
• Extensibility: this is something which is still in a very early brainstorming phase, so no ETA, but one of our ultimate goals would be to allow users to eventually be able to completely replace a specific pass. For example, an user could decide to write their own version of the SkyboxPass which could totally replace our existing internal one, as long as the correct signature is used in terms of input and output resources
  

You can already have a look at the current RenderGraph URP path in our public mirrored Graphics branch as all the internal passes and features were ported. This is currently disabled to users, totally undocumented and hidden, as all the low level optimizations are still missing and very WIP, but if you are curious you can start to have a look. Just keep in mind that lot of API will change by the time we release it


You will hear much more details and previews as we get closer to shipping it!


And a final preview screenshot showing a full URP frame in the RenderGraph Viewer

 

yes since both pipelines will be based on the same RenderGraph system in the future, porting features or extensibility APIs between each other will be much simpler, and this is all part of the long term pipelines unification initiative.

We are still at the "overhaul URP" stage so it's still early days regarding URP/HDRP unification, but ultimately that is the long term direction