URP vs HDRP: choosing the right Unity render pipeline
Your target platform list may have already decided; I measured HDRP's volumetric and SSR bill, URP's mobile advantage and what a late pipeline switch really costs.
The demo looked great, the Switch build did not
In November 2024 three of us were building a vertical slice. We picked the Unity render pipeline in five minutes: HDRP, because the volumetric fog looked good in Scene view. The target platform list was a spreadsheet nobody opened that day — Steam, Nintendo Switch and a possible Quest port. Nobody on the team had shipped anything on HDRP before; the call rested on a screenshot.
In week five we tried the Switch build. HDRP does not build for that platform at all; HDRenderPipelineAsset expects compute shaders and a DX11/Vulkan/Metal class API. Quest hit the same wall. So this was not a setting we had missed, it was the very first decision.
Rolling back took 11 working days: 190 materials, 60 lights, two VolumeProfile assets and four custom shaders. The URP vs HDRP question could have been answered on day one with a five-minute platform table. I turned those five minutes into 11 days, which is why I am writing this. Since then a platform table goes into the first commit of every project, with the pipeline row written into it.
Your platform list has already made the call
These days I start the pipeline decision with a device table, not with art direction. HDRP is not supported on OpenGL ES, Nintendo Switch, Quest or WebGL. If any one of those four lines is in your project, the discussion ends there. That is not taste, it is Unity's official support matrix, and the release notes say the same.
The Universal Render Pipeline has no such cut-off. You ship from a mid-range GLES3.0 phone all the way to Xbox Series X with the same UniversalRenderPipelineAsset structure, defining one asset per device class and wiring them through QualitySettings. Splitting renderer assets by device tier makes carrying a low and a high profile in one project straightforward. You can split HDRP the same way, but its floor stays HDRP's floor.
To measure the baseline I ran a simple test: RTX 3060, 1080p, an empty scene with a single directional light. URP took 0.9 ms of GPU time, HDRP 4.3 ms. You pay that 3.4 ms before placing a single mesh or material; the depth prepass, motion vectors, GBuffer and the volumetric froxel grid sitting ready are not free. I took the numbers in RenderDoc rather than FrameTimingManager, because in-editor figures ran misleadingly kind to HDRP.
Memory tells the same story. In that scene at 1440p, HDRP's RTHandle pools held roughly 640 MB against URP's 180 MB. On an 8 GB card that gap comes straight out of your texture budget, and no amount of turning down Unity graphics settings gives it back. In the same test HDRP's shader variant cache also added a 40-second compile stall on first launch.
What URP wins on mobile and mid-range PC
I built the same scene in both pipelines and measured: 420k triangles, 38 lights, SSAO on. On a GTX 1650 at 1080p, URP came in at 7.1 ms and HDRP at 15.6 ms. If you are targeting a mid-range card, that gap is the difference between 60 fps and 45 fps. Both runs used identical assets, shadow resolution and shadow distance, so the gap is not a settings artifact.
The Forward+ path that arrived with URP 14 removed the eight-lights-per-object limit. I can now shade more than 200 point lights in a single pass without moving to deferred or hand-splitting lights into groups. That limitation used to be one of the honest arguments for HDRP; it is not any more. Cost grows with screen coverage rather than light count, so narrow spot lights come out nearly free.
On mobile the real win is bandwidth. On an Adreno 730 my budget for 60 fps was 16.6 ms; URP's single-pass forward path keeps MSAA 4x in tile memory and folds post-processing into one UberPost pass. In one experiment where I split bloom and tonemapping into separate passes, 2.4 ms came back from bandwidth alone. Every millisecond saved on a phone is thermal budget too; across a ten-minute session frame time drifted 15% less.
Whatever is missing I add through ScriptableRendererFeature: planar reflections, an outline pass, custom decals. Winning back a few of the things HDRP gives you out of the box is two or three days of work. Winning back HDRP's baseline cost is not possible at all. I keep those features in a separate assembly so they never load in the low-tier device asset.
The HDRP bill: volumetric, SSR and path tracing
The features that justify HDRP are real, they are just not free. Volumetric fog is froxel based and gives correct per-light scattering; in the Fog override I measured 1.3 ms at Medium quality and 3.6 ms at High (3060, 1440p). That is a serious slice for a single effect. Its visible contribution also collapses once half the scene is interior, while the bill still arrives every frame.
ScreenSpaceReflection floated between 1.8 and 2.4 ms at 1440p and still cannot reflect anything that is off screen. The ray traced variant needs DXR hardware and climbed to 5.9 ms in the same scene on a 3060. The HDRP performance argument usually knots up right here, at the price tag on individual effects. Indoors I got 60% of the same look from planar reflection probes for 0.4 ms.
Path tracing is not real time. It accumulates samples across frames; a clean 512-sample frame takes me 20 to 40 seconds. It is an excellent tool for cinematics, key art and marketing renders, but it is not an option for gameplay. So I keep it out of the pipeline decision entirely and run it in a separate render scene instead.
Those three are the right answer for an interior-heavy, controlled-camera, visually driven project shipping to PC and console. But once you push HDRP down to its lowest settings to cover a wide hardware range, what you are left with looks a lot like URP. If you cannot explain why you are still paying the baseline at that point, the choice was wrong. And with nobody on the team who knows HDRP's volume layers and exposure chain, the bill goes up another notch.
Shader Graph or hand-written HLSL?
Shader Graph looks portable across pipelines, but that is only true at the master stack level. The moment you drop a Custom Function node into the graph and include URP's Lighting.hlsl, that graph stops compiling under HDRP. Portability holds exactly as long as you do nothing special. The code it generates is not readable either; debugging means scrolling 900 lines of Show Generated Code output.
Writing HLSL by hand means binding yourself to a pipeline directly. In URP you lean on the functions under Packages/com.unity.render-pipelines.universal/ShaderLibrary/, while HDRP hands you a completely different lighting API built around SurfaceData and BSDFData. Porting my toon shader to HDRP meant rewriting about 70% of the lines. Now I pull the lighting maths into a shared .hlsl file and include it from both sides; porting is still not free, only cheaper.
Variant count feeds into the decision too. Shader Graph is generous with multi_compile; a set of four graphs pushed shader compilation to 11 minutes. Converting the unnecessary ones to shader_feature and stripping with a ShaderVariantCollection brought it down to 3. My rule is simple: materials the art team will touch go in Shader Graph, hot-path and platform-specific shaders get hand-written HLSL.
Switching mid-project, and what I recommend
I tracked the bill for a migration once, and the numbers look like this. Of 640 materials, Render Pipeline Converter handled 68% automatically; I fixed the remaining 205 by hand. Most of those used custom shaders or detail maps, and the converter quietly assigns them an empty Lit material. Do not move on without reading its report; that is the only place the silent failures show up.
Lights are the sneakiest part. HDRP uses physical units — the sun sits around 100,000 lux — while in URP the same light carries an arbitrary intensity value. The converter applies an approximate multiplier, but in a 60-light scene I had to rebalance 20 of them by eye. After that came a full rebake of lightmaps and reflection probes: six hours of machine time.
On the post-processing side both pipelines use the Volume system, but the override sets do not overlap. Exposure, Fog and ScreenSpaceReflection do not exist in URP; ColorAdjustments plus hand-written renderer features take their place. Then there are third-party assets: every shader package you bought from the store carries its own target-pipeline problem. The total came to two people for three weeks, during which not one new gameplay feature shipped.
Here is my decision table. If mobile, Quest, Switch or WebGL is on your list, or you do not yet know the hardware you are shipping to, pick URP and stop debating. If you target PC and console only, can hold a GTX 1660 as your floor, are building an interior-heavy visual game and have a full-time graphics programmer on the team, HDRP earns its cost. If you sit between the two, take URP and close the gaps with ScriptableRendererFeature — and make that call on day one of the prototype, not in week five.