Huge performance hit with HDRP vs Built-in pipeline

Hello,

I'm working on the new version of my tennis game using Unity 2019.1.14f1 + HDRP 5.16.1 .

And I just compared the performances with my previous tennis game, in 2 nearly identical views, using Unity 5.6.7.

On the top right of the screenshots, I'm checking the GPU usage is ~100% ; on the bottom right, you can see the CPU usage.

My rig : Widnows 10 + Intel I7@4.6ghz + 32GB + NVidia GTX 1060 6GB at 1920x1200, with the latest NVidia drivers.

Only post processing effects in both games for the test were exposition & bloom.

In build, simple scene, no shadow ; 165 vs 590 fps, HDRP is ~250% slower :




In build, complex scene, even the crowd has shadow ; 125 vs 315 fps, HDRP is ~150% slower :




Note : each crowd mesh includes dozen of people, not only one.

The legacy game uses the deferred path, because the forward path was much slower with the stadium shadows.
The new game uses the forward path, because the doc states it's faster ; although I tried the deferred path and the performances seemed similar.

Both games use realtime GI + linear color space.

Both games use reflection probes. The new one uses 5 instead of 1, but after checking, it doesn't change noticeably the performance.

Here the stats from the editor for each screenshot, top left is HDRP Simple, bottom right is Legacy Complex :



The new games use materials for the stadium instead of composed textures, and thus there are more draw calls, although nothing crazy (any good PC rig can handle thousands of these).

Note : the stats with in Unity 2019.1 seem bugged, as the tris & verts counters count only the skinned meshes ; disabling anything else doesn't change them. Even the shadow casters wrongly says 0 for the complex scene as the shadows were on.

So anyone would have any idea what's going on ? Are there obvious mistakes that could create such a performance hit ?

Thanks in advance for any tip !

 

AFAIK, HDRP is not done so there's that, and also it's supposed to be really good and fast when you take advantage of its strong points, like using a lot of lights.

It looks to me like your game may be better served by LWRP or Built-In.

 

Note : I had mistakenly tested with my 2019.1.12f1 build.
With the 2019.1.14f1 build, the complex scene fps are up to 125 from 100. It's a bit better, but it should be at least at 200 fps to be reasonable considering the "complex" scene isn't that heavy.

I guess now I have to test with 2019.2 ...

However, between the 2 Unity versions, I also had turned off the Contact Shadows support (although I didn't use them), so maybe the fps boost came from there.

@AcidArrow ,
I'm already fan of the HDRP in a general way ; it's hard to set up & dig into at 1st, but overall, it's a major step up over the legacy built-in path. And the LWRP has some serious quality limitations compared to the HDRP (I'm in the process of changing the legacy assets seen in the screenshots above ).

I found some HDRP optimization advices by a Unity dev, I'm going to deep into them and see if anything has a meaningful impact.

 

The fps boost wasn't from the Unity version change, nor the Contact Shadows support, but from switching to the Deferred rendering. So it's actually faster than the Forward rendering...

After I turned off everything unneeded in the HDRP asset & the Frame Settings, and it didn't seem to change a single anything in term of performances.

I turned off the SRP Batcher and got back my tris & verts stats. The complex scene gives 5M tris + 6 M verts, vs 1.6M tris + 10M verts with the Built-in version. In the simple scene, it's 64k tris + 70k verts vs 31k tris + 55k verts, so it's much closer. I'm not sure what to think about all these numbers. It could plead for a 50% slower rendering, I guess.

I'm going to try to display the old assets in the HDRP game, it might ease the testing.

 

Ok, I put back the old stadium & most of the props. It now gives for the complex scene 1.9M tris + 8M verts vs 1.6M tris + 10M verts with the Built-in version, and 170 fps vs 315 ; still 85% slower for the HDRP.

I'd settle for a 20% loss, so hopefully the future HDRP versions will be a bit more optimized, because right now I don't see what else I could do to speed things up.

 

These benchmarks are kinda pointless, measure the gpu cost in ms if you want to get some real figures (don't use FPS as it doesn't really tell that much). Also would suggest testing on weaker GPU to get some use cases where the perf difference actually matters: 170 fps is probably fine for 100% of your player base..

As additional note: do you really need realtime GI for this?

 

@rizu ,
fps is what actually matters for the end user, it's the only metric that counts in the end. Plus it's super easy to test, and here I need to check ballpark figures, not small gains.

A few user expects to play with their 200 hz gaming monitors, a lot more expect to play with their 120/144 gaming monitors. Others will be expecting to play in 4K. And others will be playing with less powerful GPU, as you have pointed out.

Plus, it's not 170 fps with my current assets, but with the old ones ; moreover I expect the final fps to lower more & more as I'll be adding stuff along the way, so now is a good time to get a general idea about where I stand.

Lastly a GTX 1060 is pretty mid-range now, so it's a good reference.

So anything result under 200fps in my little test is problematic.

BTW, what would you use for measuring the GPU cost in ms ?

 

For end users, yes, but you are now posting on a developer forum. Using FPS for perf measurements is bad because it is a sum of many things, you don't really see where you actually sink the perf at all. Use Unity's profilers to see what is expensive and what is not and you don't have to guess or use some super rough ballpark methods like measuring FPS.

Those few with 240Hz 1080p monitors most likely got a decent GPU already

All this being said, at such light use case project as yours is, you can't beat built-in renderer in perf with HDRP, or even match it. HDRP has more initial overhead.

 

My initial goal was to see how the performances compared between the 2 engines. Thus the Fps was the best tool for that.

Considering the huge performance hit, my 1st idea is that I did some newbie mistakes (I had read the HDRP doc, but there are really sparse).

Diving into the Unity Profiler gives very little bit of info, except "waiting commands" without further detail for nearly 75% of the rendering thread ; and anyway, the rendering thread is CPU time, not GPU time, so it's nearly useless. So it's not that that will tell me if I did a mistake or not, and what could be optimized.

So if the HDRP is nearly 100% slower than the Built-in in a normal case, I think it's really a problem.

In another topic about this performance issues, I read a Unity dev bragging the HDRP would shine when using 200 lights on screen. Ok, great, but how many games actually need to show 200 lights most of the time ?

A base scene like mine shouldn't be that much slower. A 20% hit would be understandable due to the extra stuff, but nearly 100% isn't.

So I still hope I missed something important, or that they optimize the hell of it for the official release...

 

No it's not. HDRP is supposed to scale really well. Built-in doesn't scale that well. It's supposed to be used when you need a ton of lights and other high end features and it's intended for high end platforms. It's supposed to have a lot of overhead, but then scale really well.

If that's not suited for you, use LWRP or Built-In.

 

@AcidArrow,
I already answered you above...

 

You did, but if you are a fan of HDRP, you need to accept that it has higher overhead than the other options, that's how it was designed to be.

 

I'm more after understanding what's going on, so after I could do a more educated choice, wether it's tuning some of my assets, working on the rendering side, or like you said, just accept it's slower. Right now, I'm in the blank, and that would be stupid to not look more into it and not fix the things I could fix...

I've read all the blog posts about HDRP, all the HDRP doc, and a few posts on the forum by Unity devs, and right now, I feel it's really hard to know what's the deal with HDRP (just check that other guy post to which I answered as well, he's in the same boat than I) ; I guess there's a higher overhead, but it should be explained & documented in details, so we could understand what we can do to limit it, to take advantage of it (I hope it's not only to render 200 lights, coz that would seriously limit the utility of the HDRP).

Right now HDRP is the obvious choice of rendering quality, but the performance cost shouldn't be that high.

I'll quote 2 things from that blog's post : https://blogs.unity3d.com/2018/03/16/the-high-definition-render-pipeline-focused-on-visual-quality/

Both of these things made me think that HDRP was not the slow hog I got with my test scene. (except if we consider that a GTX 1060 is too old to harvest the HDRP awesomeness)

In that post, they also never talk about overhead, nor lower performance. They only state you need recent hardware.

And the 1st quote could mean I didn't configure something correctly, although I checked everything I could think of, but as I don't master all this, I may have had some oversight, thus my reaching for help in this forum...

 

I just did another test, on the complex scene, but without the shadows on the crowd, and using the legacy stadium in the new game, in exclusive fullscreen mode (before I had tested in windowed mode ; exclusive mode is ~5% faster with Unity 2019, and ~10% faster with 5.6).

I wanted to see the fps loss when using a bigger resolution, so I tested 1920x1080 vs 2560x1440 : this is 77% more pixels ; here the results :
- Built-in : 373 vs 235 fps ; 59% slower
- HDRP : 203 vs 134 fps : 51% slower

This is quite similar. So if there's an overhead, it's mostly in the pixel shaders, which means there's a real performance issue right there, as quality wise the shaders are pretty similar looking when using 1 directional light, GI, normal & mask maps.

 

You could try 6.9 HDRP, which seems a bit newer.

 

New test with Unity 2019.2.2f1 + HDRP 6.9.1, in the complex scene, with the new stadium, no SSAO nor FSAA, 1080p vs 1440p :

- 2019.1 : 156 vs 103
- 2019.2 : 154 vs 107

So the new version is a tiny bit slower in 1080p and a bit faster in 1440p. I'm not sure what to think about that.

Bonus note : the SSAO in HDRP 6.9.1 is completely broken (I opened a new topic about that issue )

Double bonus : the Fps in the 2019.2 editor are super low (around 60 fps instead of ~85) ; if it gets a bit more low, I won't be able to easily test my gameplay in the editor anymore...

 

As one of the particularity of the SRP is that it's scriptable in C#, I tried to build using IL2CPP, thinking it may help to run faster.

- still 2019.2, 1080p vs 1440p : 147 vs 108

So it got a bit slower in 1080p and a tiny mini bit faster in 1440p. Once again, I don't know what I should think about that...

 

So I downgraded my game to use Unity 2019.1.14f1 Built-in pipeline.

In the same condition than the previous 3 messages, I got :
- 1080p vs 1440p : 260 vs 174
- compared to the best HDRP, it gives : +~70% vs +~60%

I guess the lower boost on 1440p means my GPU is closer to its limits.

Side note :
Test with Light Probes, 1080p vs 1440p : 243 vs 171
Test with Light Probes + SSAO, 1080p vs 1440p : 218 vs 145

PPSv2 SSAO @1080p takes about 0.5ms, which is in par with the one from HDRP 5.16.1 .

So I'll stick to the Built-in pipeline, at least till the HDRP is stabilized & optimized, and works on Intel Iris. HDRP looks better for me, though... (but apparently, not to my users nor the Unity users )

EDIT:
the poly count is slightly lower in the latest version of my stadium, but it gives less than a 1% boost. (I just moved a bit the camera in the HDRP test to get more or less the equivalent of the new stadium )

 

Well, I wouldn't create a game on HDRP to target such devices ;p

What you could try is adding volumetric fog, GPU particles, subsurface scattering and deffered decals to the built-in and then compare. Or replicate this setup and run it at 30 FPS, 1080p on PS4. To this I'd say: Good luck

 

@alexandre-fiset ,
you may want to read above : https://forum.unity.com/threads/hug...drp-vs-built-in-pipeline.729416/#post-4870874 , or here : https://forum.unity.com/threads/can...e-for-the-most-beautiful.734306/#post-4938338 .

Note : I'm not targeting IGPs, I just want to support them as they are a non-negligible part of my income.

 

You say you need realtime gi, SSS for character skin etc, but none of your screenshots really show either of these clearly - which just makes one wonder why even bother requiring them. LWRP (/URP on 2019.3) would give you these same visuals with less overhead and would be more future proof.

 

@rizu ,
you may want to read here as well : https://forum.unity.com/threads/can...e-for-the-most-beautiful.734306/#post-4938338 ...

 

You will need to be changing pretty much everything from the probes, the lights, the shadow settings, the HDRP volume asset (global) and the HDRP config asset for engine.

There's a lot to go through to get optimal performance, but if you can share your full light settings, your full global volume settings and your faull HDRP asset settings we may be able to spot a problem or two.

HDRP's design will cap your framerate lower but also stay above say, 30fps much longer than built-in will assuming built-in was tasked with having a similar feature set rendered. That's the hallmark of modern AAA graphics engine design - it is not about the highest FPS you can achieve, but allowing the engine to maintain a framerate under some pretty heavy loads by managing bandwidth really well.

By contrast, built-in is much much closer to Universal pipeline, which is direct (except for the lights and SRP batching), so perhaps that pipeline is actually more suitable? You can only get Universal Pipeline on 2019.3 (beta 2 and above) though.

I do not think the Intel Iris is a good fit for HDRP. HDRP is designed for consoles and up, basically, but there is still plenty to tweak. And you will have to tweak.

 

I saw the post but it's a lot of text All I'm saying is that I don't really see the need of those mentioned techs on your in-game screenshots. You could see more noticeable improvements by just improving the game assets themselves.

 

@rizu ,
I'll do it in short then..!

Unity introduced the HDRP as looking better, using less VRAM, and being faster than the Built-in engine, without indicating any condition to the extra performances except having a modern compute-shader GPU.

So I found out it's true, except for the extra performances, thus this topic.

I also found out it's really nice & easy to use once the initial learning is done, as it's very fast to make everything look right.

If you can't notice the difference between the HDRP & the LWRP (or the Built-in), it's good for you. And from my polls, it seems to turn out that most people are like you. Me, I can spot the differences even on my screenshots. Especially on my screenshots.

Thus my big disappointed to being forced back to the built-in pipeline.

Side note : improving my assets isn't incompatible with getting the more modern lighting system of the HDRP.

@hippocoder ,
what I said to rizu, plus :

I already redid everything, we are forced too, as almost nothing works the same...

I already checked everything I could (as exposed in this topic). From all my fps tests above, I think we can guess the issues are mostly with the shaders, and at this point there's nothing we can do about it except hoping they'll be optimized in the future.

I don't know if you're a gamer or not, but I have a 144hz monitor, and once I started to play games at 100 fps, there was no turning back, and for a tennis game, 120 fps is really neat. Just reading "30 fps" makes me shiver... ...

As a side note, the loss of fps on my Intel HD 3000 was less bad than on my GTX 1060 (using my special IGP render mode on the IGP, and the normal one on the GTX).

 

I didn't say there isn't possible visual difference between the renderers themselves, but the advantages can be subtle if you don't need the extra featureset from HDRP (which is one of the main strengths of HDRP - it does a lot out of the box).

What I did try to tell however few times already was that looking at the in-game screenshots you've posted, it doesn't look like you are getting notable visual gains from using feats like realtime GI or SSS, both which you brought up for arguments for not using LWRP. Your poll images didn't indicate you utilize HDRP feats extensively either which is just another reason to recommend LWRP (or built-in) instead.

 

I optimized a bit more my stadium to lower the poly count, and now, I get, still for built-in, in the same condition than the last test :

- 1080p vs 1440p : 270 vs 175
- +10 fps ( = ~4%) vs +1fps

I guess it means at 1440p, the bottleneck is the pixel shader, while at 1080p, the poly count still counts (shameless pun intended ).

Note : I've just upgraded to 2019.2.4f1, but I don't think it should change anything to the Built-in engine.

 

Built-in will never change apart from being removed one day or fixed if bugs occur. But you are comparing FPS not millisec differences.

Do you know why that is a terrible mistake to make?

 

Sorry to bring up an older thread but...

@hippocoder In all seriousness I would like to know why it's a terrible mistake not to compare ms differences. I'm not very technical so I'm curious.

I've converted my project over to HDRP and noticed a large drop in perf as well. In terms of ms, built-in is at ~1ms and HDRP is at ~11 for the same simple scene (Main cam, BG cam, 1 particle system).

 

To put simply, if you measure milliseconds you can compare the performance because it is linear. What this means is that 2ms costs twice as much as 1ms.


But measuring fps is a curve, so it is not possible to measure and reason about it. FPS becomes progressively less meaningful the higher it is. 200fps is not twice the cost of 400fps, not even close!

You'd be thinking "Damn, it's 300fps but 200fps when I use this effect! That means the cost of this effect is a huge 100fps!" but that's not too big. It's only a few millisecs, so you can see how you will get useful measurements from ms and not fps.

I do use fps as a term in some discussions, depending on if the person I'm speaking to is able or willing to use millisecs. So it's fine for a general chat, or a review website but a disaster for a developer.

http://www.joshbarczak.com/blog/?p=1248 among several online articles that explain it better than I have.

 

Probably want to revisit that BG cam, because HDRP has a specific way of handling multiple cameras and it's a disaster if you do that, but that's another topic, so in this case you're likely just using HDRP like you did Builtin, and you can't do that.

Multiple cameras for rendering a single frame is a bad legacy unity-specific design and for HDRP, you want to use the compositor, or check very carefully how much you're asking the camera to do if rendering to texture. Quite different to Builtin.

Also HDRP does a bunch of work up front but the difference should not be a whole 10ms.

 

Also, note that the Compositor isn't in HDRP yet. It's coming soon in a release package most likely at the release of Unity 2020.1 or maybe a little before that during the beta.

 

1000ms/200fps = 5ms per frame.
1000ms/400fps = 2.5ms per frame.
If your game (or effect, or whatever) runs at 200fps, then it's twice as costly as running at 400fps.

If this calculation makes you uncomfortable, you should indeed stick to using ms instead of fps.

If not, usually, for global stuff, fps is a better metric for 1 simple reason : its precision naturally raises when required (*), and it gives numbers easier to apprehend and remember than ms. (ok, that was 2 reasons )

(*) : with ms, either you have 2 decimals and it's too much when you're above 10ms, or you have only 1 and it's not enough when you're under 10ms, or you have both and comparing require more attention, especially when you pile up the tests.

When optimizing or prospecting general performances, both with fps and ms, the trick is to remember that comparing absolute gains can often be a mistake, but with fps it's much more obvious why. Usually, you want to compare relative gains ; eg: 5ms is twice slower than 2.5 ms, and 200fps is twice slower than 400fps. (it's a bit different if your context is completely static, eg: on consoles without user-configurable rendering options)

When you optimize a single isolated thing, or evaluate the cost of a single effect, always use ms though. (like I did above with SSAO)

EDIT:
I'll add : if your goal is to evaluate a budget, then of course you're going to do it using ms. ie: if for your game you aim for 60 fps, then your budget is 16.67ms, and you're going to add-up effects by the time they take in ms till you reach that total (it's a bit more complex in real case scenario, but hopefully you get the idea ).

 

I'm just going to note here that 50fps drop from from 60fps (16.67ms->100ms so total of 83.3ms difference) means TOTALLY different thing than 50fps drop from 400fps (2.5ms->2.85ms so total of 0.35ms difference).

It's just not a good way to measure perf differences on fps at all and that's why everyone recommends against it. It has nothing to do with it being more comfortable in doing it some other way.

 

Thanks for the replies everyone! Great info!

Also I'm glad to hear that the HDRP compositor is coming (soonish).

 

I use all of this fps stuff differently. Since moving to HDRP I use GPU score to measure what range of gamer cards can run my games. I have found I need gamers with a minimum gpu score of 5000 to run my games at 30fps and the most common cards that can do that are the gtx series cards and up. My rtx card has a 20000 GPU score and I need to get fps values of 150+ on a full level scene to meet that goal as any less and lower GPU score cards will begin to get less than 30fps which isn't good.
----------------------------------------------------------------------

If there was a way to lower the huge up front unknown processing HDRP was doing by tweaking some settings I would love to know because any settings that would allow the sample scene fps to rise dramatically would mean many low end gamers can jump into my games.

My current fps is certainly cpu bound as it reduces dramatically with shadow casters and draw calls so mesh combining is my savior. If we can solve this high overhead on empty scenes that hdrp imposes then everyone can just jump on board!

*Fun fact I tested my fps in the sample scene for Unreal Engine 3rd person demo and it had no materials just a few objects and 3rd person script and I got 170fps and in Unity the sample scene with lights, post effects and materials in HDRP gives me 350fps so either unreal engine handles the fps much better on higher load or Unity is just better.

 

To even be able to make a proper comparison, you should match the PP and other settings between the engines. UE4 has scalability keyvars too that can alter the result a lot. I can dial down both UE4 and Unity HDRP a LOT down from defaults by just turning off things that are not essential. But doing random test like that doesn't really matter much unless you actually test similar settings on multiple target devices.

These renderers scale down differently on weaker hardware (where for example Unreals forward path is a lot faster on weak hw than say their deferred path, on Unity HDRP forward vs deferred perf diff isn't as notable and can be in the other direction even). For me comparison between UE4 and Unity isn't all that meaningful as long as both get the job done. What I'm most worried about is scalability as that limits your actual min spec (and as long as you are using Unity, URP and built-in are miles ahead in that part in comparison to HDRP).

 

That's my problem too did you figure out any cool tricks or settings to get the HDRP to release some of it's bloat out of the box bloat so it's a bit closer to the URP and Built-In?
i can't really turn off any of the post processing like AO or Shadows but maybe you know some more back end tricks?

You're definitely right on what you are saying about the URP and Built-In bottlenecks compared to HDRP being very differnt. Like I ran a scene with some basic post processing and HBAO/Amplify Occlusion SSAO with a 3rd person controller in Unity standard and got 1000 fps on my Rtx card and that same scene gave me 110fps on my 1000GPU scored Radeon HD5000 card so Unity built-in and LWRP are monsters for low end hardware in comparison. In all honesty if the shaders and shadows were better in those I would still be using them-especially the shaders and sadly there is no shader graph in Unity standard to make a decent SSS shader.

 

Basically go to your default frame settings (on Project Settings->HDRP Default Settings) and disable everything you know you don't need. Do same with HDRP asset. Don't leave things enabled thinking "I might use this later". If you mess with some other than on/off options, do measure the perf cost (for example the assumption is that you should keep async effects enabled - although if you need raytracing, they are disabled by design).

It's worth noting that while I can get stripped down HDRP to be closer to URP perf on my RTX 2070 Super, it will not look pretty and if I then try to run it on some weaker GPU, HDRP will still choke a lot sooner than URP does so do check the perf on your min spec target too.

 

Back in the day we would use Raster lines / T states for CRT scan line ref points so you'd measure the amount of T states remaining in your cycle by the inches, a portion of the height of your TV

 

After also experiencing a performance hit in HDRP and finding out there's a major bug in Skybox lighting in HDRP my previous perfect lighting had broken and I couldn't fix it in the newer HDRP and I lost a lot of work and motivation.
I had for HDRP finally achieved that unreal look running at decent frame rates and bam....it's over.

So after mucking around in URP I actually unexpectedly ended up recreating that unreal look as the Skybox lighting bug wasn't as bad there. After baking the lighting with 0 objects making a lightmap of 0kb-a bug in Unity needs to bake the lighting to get skybox lights to work this was the result after HBAO Multibounce and Post processing:

I get double the performance (180 to 350) with minimal tradeoff actually it's better in numerous cases than HDRP and anything missing form URP is taken care by the Shader Essientials Pack.
There's currently just a shadow bug and generally less crisp shadows but better shadows are on the URP roadmap.
All real time:

 

To me (I don't think it's just me tbh) scalability's main point is about how well does your game run and show up on different types of hardware, assuming you prefer keeping one project for all platforms.

I really love HDRP's amazing new features, shader graph, vfx, ssgi etc but at the same time I had suffered a lot on recent months trying to understand why the render loops are so slow. A typical render to texture camera for simple UI effects etc took me 0.5ms on legacy pipeline while on HDRP after culling all available Custom Frame Settings on camera I couldn't get any better than 2-3ms. I see giant blobs and even GC allocations (!?) at HDRenderPipeline culling and render functions when looking at the profiler.

As a programmer I enjoy a lot writting surface shaders (not supported on srp?) and also the scalability that brings me the legacy pipeline doing ultra lightweight rendering at the same time of very complex compute shader and deferred lighting effects stacked directly into the camera at your will (things like SEGI worldspace realtime GI for instance).

I wonder why is Nintendo Switch not considered "console" anymore (it's not on the HDRP platform list right? )
Nintendo Switch and especially recent Apple devices have a perfectly usable set of SM5 specs, compute shaders are getting really fast and even deferred rendering is not an issue on latest models for instance. Don't you think they can do better than what URP is designed for?

Even in the case of high end platforms, the more time the rendering leaves free to me, the more gameplay elements, detail, effects etc I can place in the game, it's just my oppinion.

Maybe a 100% custom written pipeline is the answer for full platform scalability control?
cheers!

 

HDRP was intentionally designed to force users to buy the highest end cards in order to use it. This is so manufacturers can make more money. This is the same trick Unreal Engine uses too. You'll never find the cause of the slow render loops because they are intentionally designed with mystery bottlenecking on purpose with proven lies like they can "scale better" which is only partially true.

Ultimately you should know HDRP is for hobbyists and maybe short films it doesn't hold a place for video games it has a lot of novel features but that's all they are just pretty but unusable effects.

If you master URP with some HBAO and Skybox lighting you can get realtime lighting on par with Segi for very cheap in URP. URP has 80% of the features of HDRP nowadays and runs 10 x faster quite literally. If you want to make games for real you should consider giving it a shot.

However having said that nowadays with the power of the PS5 you might be able to get away with the huge performance loss of HDRP just because hardware can handle it now. But if you are aiming for anything other than PS5 then don't use it. Even for PC most people can't get their hands on anything higher than a 1080 because of the scalpers and bitcoin garbage buyers and 1080 is not strong enough to run URP games properly if you intend to use any of the fancy lighting.

Just my 2 cents.

 

Wow I didn't know that, thank you for the info! I'll give URP definitively a shot

About PS5 I cannot discard any platform from prototyping because it might be PS5 and/or Switch or even mobile at the same time, depending on publishing conditions later, so I guess in my case URP is the only reasonable srp.

Btw I have tried HBAO and skybox precisely trying to replicate SEGI tests on a cheap way but quality is not even close. Although it's far away from being a complete dynamic GI solution like UE5 Lumen, segi is not only about ambient but mainly dynamic light irradiance/propagation and volumetric realtime reflections (to get something better you need RTX imo), give it a check

 

I can't tell if this is a serious or troll post.
about urp and HDRP..

Spoiler: URP is nowhere near HDRP

No volumetric fog, all current assets offering volumetrics for urp are lacking.
No good volumetric clouds, nothing close to the performance and visuals of the built-in volumetric clouds coming in 2021.
No raytracing, path-tracing, FSR, DLSS.
No temporal antialiasing.
No screen space reflections.
Nothing close to the built-in provided materials that HDRP has..
No tessellation.
Many missing post processing features.
No Screen space global illumination, which is good in 2021. (improved from 2020's version)
No visual env system, no realistic lighting.
Shadows nowhere near the quality of HDRP. In-fact, they're worse than built-in even.
missing decals features.
No shadow caching. HDRP provides caching of all shadows from all light types.
List goes on and on...

HDRP has some overhead, so you won't get crazy FPS numbers even on an empty scene.
But it does scale better if your project is 3D and demanding. Shadows alone in URP will kill your performance.
If you know what you're doing, you can get good performance from HDRP.

For example, the new volumetric clouds have a strong focus on performance and they're _extremely_ fast. Only costing 1ms on a laptop gtx 1070 with high settings.

To get a sense of how different the graphics are, check out car mechanic 2021 which is using HDRP.
Compare it to the previous game in the series, using built-in.

Although HDRP does need performance improvements still, they've done a lot for 2021.2 but there's much to do still. And hopefully they keep at it since right now it is lacking, but it's not as bad as some people make it.

 

You can make Car Mechanic Simulator in URP without any issues. The graphics in that game look pretty average but the materials are nice but URP can do this too since they've upgraded the shaders for it a while back and the cheap URP Essentials pack contains all those extra car kind of materials and much more heck even nodes for shader graph contains some wicket skin shaders that HDRP cannot match.

You throwing big words out like SSGI, Volumetric Clouds, Path Tracing, Ray Tracing and those features are rarely used in games you might get lucky to use 1 but you won't be seeing games that combine multiple of these even Cyberpunk was struggling with it's real time tech. It's just not practical to boast about these features as if they are practical for games.

Most of the missing features you said was once the case with URP but it no longer is for example fog is fine, shadows are fine, materials are fine, visual environment and realistic lighting and skybox, AA and post effects are fine.
Both engines have shader graph and visual scripting but the biggest difference is URP is ready now there are is no need to wait for updates and with HDRP people are still waiting for new features or performance updates and they will be forever.

You need to do research and digging on tricks and tips and may need the asset store for both URP and HDRP in different ways to but it's all there with the right level of digging.

It's up to the original poster to evaluate what is right for them but his original post was about slow render loops on performance being the biggest issue and for that HDRP isn't going to work but my comment about 80% does hold true with all considerations in check.

The image I posted above has very nice graphics to get anyone started with 375 fps to spare as seen in the performance top right that scene is nothing more than standard scene with the trees and hut from SEGI with good lighting, some built in post effects like ACES, Color correction, baked REAL TIME skybox lighting with the only extra addition being the HBAO tweaked to fit nicely with it's multi-bounce AO to simulate some GI.

Either way you're going to encounter different challenges with URP and HDRP but I was not able to solve the issues with HDRP but I was with URP. That's my 2 cents.

At least lets appreciate the days of baked lighting being over now that image I showed higher above is all real time since now all you have to do both in URP and HDRP is bake the skybox and it's 0kb and produces some crazy real time lighting!

 

fog is not fine, shadows are not fine, realistic lighting is not fine.
Your image is an empty scene with little to nothing, the real issue is when you actually have a big demanding 3D scene. If you have some punctual light realtime, shadows alone will kill your performance. where in HDRP you can cache all of it.

Temporal antialiasing is still not here, SSR not here. No volumetric fog/lighting.
Comparing small or empty scenes is pointless.

And the worst part if slow development and limitations caused by all the platforms URP supports.
Everything they do will take into consideration mobile platforms and switch.
Including what method of SSAO they use, SSR.
Many features will not be added because of this, some will take considerably longer to develop, and some will make big compromises because of these platforms.
SSAO uses Alchemy AO, reason is weak hardware.
None of the post processing runs in compute.

And this list will only get bigger and bigger, HDRP will keep adding new advanced features, while URP has to consider all platforms.

I mean, we're only now in 2021.2 getting decals, deferred renderer, and so on for URP.
This paints the future for URP. HDRP will keep getting advanced features at a relatively fast pace where URP will have to consider all platforms and based on recent years be much slower with many features not being added.

HDRP is getting an ocean/water system in 2022, the list will keep getting bigger.
I say this to point the difference between the two. In URP, you'll have to use assets left and right to make up for it's weakness when it comes to high fidelity, fight with assets yet again, and hope to find an asset that does what you want, and then hope that it's good and the author active. There's no good volumetrics asset for urp so far.

If you're targeting high-end fidelity for PC and consoles, HDRP wins hands down.
Some people stay away from it because they think it's complicated and hard to use.
And it is, compared to URP/built-in, lighting alone might be a frustrating experience at the start. which is why many people might get frustrated or not know how to manage performance, or get the right visuals they want. Which is okay. Although once you understand it, it'll be a lot more fun to work with. It seems daunting at first, and there's tons of options, but a few days or weeks of heavy use and you'll get used to it.


URP isn't bad, or impossible to create good graphics in, urp is similar to built in, or will be eventually once they get parity, graphically speaking, so you can still get nice graphics. Especially if your game style is more creative. Most games out there created with unity are made with built-in, URP can achieve that. Many of these games look quite nice. And unlike built-in, it's going to keep getting new features so it'll surpass it graphically.

but in the end, HDRP does high-fidelity better, and is built for that purpose with faster development and features. And it's not held down by supporting platforms such as mobile.
it'll keep getting advanced features, and at a faster pace.
Where URP will refuse to add many of them and the ones that do land will make compromises due to it's wide platform support.

 

Can you instead share some good documentation/guides for setting up HDRP "the right way"?

 

https://blog.unity.com/search?q=hdrp