Improving Performance In HDRP (7.3.1)

[OliverVSmith]

I was wondering if anyone had any tips on improving performance in HDRP?

We’re at a point where we’ve optimised as much of the game as is possible at this point, but still find it very difficult to get a solid 60fps in the editor (on decent machines, and occasionally scratch 60fps at the very start of the game in Build).
Our bottleneck seems to be HDRP as the render loop takes up at least 10-11ms per frame on the CPU.

I’ve attached a sample profile.

Any suggestions would be greatly appreciated

Link to Profile: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

For reference, this particular machine has an i7-7700k (@4.2GHz) and a GTX 1070 8GB.

Edit: Added our HDRP asset for that Quality Setting but it makes little to no difference at other levels

5775544–609001–HDRP_Asset.zip (2.42 KB)

[cloverme]

I’ve got the same situation going for me, I have an i9-7900X with a RTX 2080ti 11GB gpu and 32gb of ram. I’m using HDRP 7.3.1 in Unity 2019.3.10f1. In profiler, RenderPipelineManager.DoRenderLoop_Internal() is taking like 30-40% of the main thread, 20-25% of that is Inl_HDRenderPipelineRenderCamera.

When I was on the built-in renderer I was seeing 110-120fps before moving to HDRP and adjusting everything to the new pipeline (now at about 50fps). Adjusting the quality settings doesn’t really do that much to offset the difference any, like quality on volumetrics, etc. What’s interesting, is that if I downgrade my GPU to a 1080ti 11GB, I get the same framerate. So there’s something going on with the CPU utilization and HDRP and how the engine is using the CPU for some type of processing and not really taking advantage of the GPU in certain circumstances for some particular workload. So there’s some kind of bottleneck throttle happened somewhere either in the engine or hardware platform set when HDRP is used.

I read some advice that you can try to disable the SRP Batcher to see if that helps, but there doesn’t seem to be any way to disable it in HDRP 7.3.1 as it appears to have moved someplace in the maze of options.

I totally get that HDRP is for “next generation hardware” but it seems like the current production version has a crutch on the CPU for some of the workflow pipeline.

[hippocoder]

@cloverme

I totally get that HDRP is for “next generation hardware”

No, it’s very smooth on an AMD card from late 2014, so you will both have to file bug reports or take a much closer look at where your CPU time is being spent.

I get you have slowdowns but I spent 2 years on HDRP solid (almost daily) and tested it with a bunch of GPUs including a 980, which is easily equivalent to the OP’s card. And it flew, really flew. 200FPS+ on busy scenes.

So the assumption it’s all next gen is totally wrong. It’s designed for current gen consoles (the originals, not the refresh) and can scale to next gen with RT.

You guys are probably doing bad dev practises. It can be slow if used badly or you assume you can do the same practises as built in. For a start design out multiple cameras. These things do totally different things in HDRP. Each camera (by default) does a huge amount of up-front optimisation work to absorb larger workflows later.

You can’t just stack em and leave em (if that’s a thing being done).

I get I probably sound harsh, but how else will you stop assuming and start digging? Provide more info and better answers can be had.

[cloverme]

@hippocoder

You guys are probably doing bad dev practises. It can be slow if used badly or you assume you can do the same practises as built in. For a start design out multiple cameras. These things do totally different things in HDRP. Each camera (by default) does a huge amount of up-front optimisation work to absorb larger workflows later.

I get what you’re saying… Is this a totally anecdotal post on performance? Pretty much and sure, there’s some new performance tools that Unity has released and I haven’t tried those, but it’s kind of like when most people have a problem, they’re looking for the low-hanging fruit first.

That being said, if there’s a shift in the approach towards development (other than ECS/DOTS) towards changes in HDRP, that would be good to review. I’ve only got one camera, but good to know anyways. If you have any recommendations towards some best practices after switching over to HDRP, that would be helpful. Am I the perfect Unity dev? no… am I instantiating 10k gameobjects in update() and do/while loops? no.

I’ll keep on keeping on, thanks for the tips.

Update:
This is also in-editor framerate (outside of editor build is over 100fps)

[snacktime]

The main thread cost is substantial and could be improved greatly. It’s completely valid to pressure them on that point.

The main thread hit can be very significant even with everything done right, at settings that you need just to be competitive in your genre. Depends on the game.

Big picture having followed the bleeding edge for quite a while, I think the plan is to solve this via DOTS for the most part. Not by trying to solve it in SRP/HDRP core. The DOTS renderer in 2020.1 solves a piece of it. There are a number of other significant pieces that are a ways off.

So big picture if you are doing it all right and still under pressure. DOTS is what you need most likely. Not just for the rendering improvements but to move everything non rendering related that you can off the main thread.

[OliverVSmith]

@hippocoder

You guys are probably doing bad dev practises. It can be slow if used badly or you assume you can do the same practises as built in. For a start design out multiple cameras. These things do totally different things in HDRP. Each camera (by default) does a huge amount of up-front optimisation work to absorb larger workflows later.

So, may well be doing bad dev practices for HDRP. I don’t know, there’s just a lack of info on this. This is why I’m asking the question to begin with…

We aren’t using multiple cameras (well we have multiple but only one is ever active at any given time). Well aware that things need to be done in a different way to built-in and we’ve followed as much advice as possible from across the forums.

HDRP on the CPU is using 10-11ms every frame pretty much regardless of settings changes we make, so I don’t know what else to try, we don’t really have any indication what is causing it.

[snacktime]

@OliverVSmith

So, may well be doing bad dev practices for HDRP. I don’t know, there’s just a lack of info on this. This is why I’m asking the question to begin with…

We aren’t using multiple cameras (well we have multiple but only one is ever active at any given time). Well aware that things need to be done in a different way to built-in and we’ve followed as much advice as possible from across the forums.

HDRP on the CPU is using 10-11ms every frame pretty much regardless of settings changes we make, so I don’t know what else to try, we don’t really have any indication what is causing it.

You really need to start with knowing what stuff costs. I see you have skinned meshes there. What’s the cost of that in an otherwise empty scene? You should know the cost of every major moving part really. Start with a baseline of nothing and then start enabling different parts of your game. And use the profiler don’t rely on the stats window.

Just keep narrowing it down and you will eventually find what the issue is.

[OliverVSmith]

@hippocoder

I get I probably sound harsh, but how else will you stop assuming and start digging? Provide more info and better answers can be had.

I also provided the HDRP asset we’re using (in order to see if we’re making any obvious settings mistakes) and a profiler dump in the hopes someone may spot something I’m missing.

To provide more info, it’s a city builder.
We’re using one Directional Light on Mixed
A 2048 x 2048 Unity Terrain
Baked Lighting and Reflection Probes where possible
Some Post Processing but it doesn’t seem to alter frame render times
Baked Occlusion Map
Utilising GPU instancing as much as possible on our shaders/materials

We have Skinned Meshes but they have very little to no impact initially (later on yes, causes an impact when we have lots), disabling them has no impact in this scene.

Here’s a screenshot from our profiler (just after launching the scene)
I would Deep Profile but that seems a bit useless in HDRP at the moment unfortunately.

[OliverVSmith]

@snacktime

You really need to start with knowing what stuff costs. I see you have skinned meshes there. What’s the cost of that in an otherwise empty scene? You should know the cost of every major moving part really. Start with a baseline of nothing and then start enabling different parts of your game. And use the profiler don’t rely on the stats window.

Just keep narrowing it down and you will eventually find what the issue is.

Oh we never rely on the Stats window (other than as a general guide to Tri counts and FPS), all our debugging we do using the Profiler.

We have a firm grasp on the costs of every other part of the game, all our code that is.

You’re right though, we will have to (and have been) tear it back to basics and build up with the rendering side and see what adds the heavy rendering costs.

If you guys have any advice or links to any good pieces on optimisation and good practices in HDRP I’d love to see them

[Bordeaux_Fox]

I just went quickly over all the post in this thread.

From my experience: I already made two 3D games with HDRP.
My first game actually used HDRP when it was still in preview. It was very painful to work with it back then, but I managed it. The point is: Our scenario was photorealistic with a lot of realtime point lights casting realtime shadows. We also used Enlighten, means dynamic realtime GI. With my RTX 2060 and Intel i7-9650H, I get roughly 60 fps. But on our map we have some small areas where too much shadows overlapping, means when the player goes there, the fps is about 30.

My second game, which is in a more stylized appearence used the new HDRP without Enlighten. The setup is not as heavy as the other game. Again same specs. It runs with about 60 to 90 fps (depening what is going on). Very heavy of enemy animations and high quality physics. That’s the actual bottleneck of the game.

General tips what I’m learned from HDRP, but actually it applies to like every other engine:

• Choose the quality of post-processing effects based on your fps budget. You can easily kill the games performence with Depth of Field sampling a 1:1 image. So use half or quarter size.
• High quality contact shadows are also very expensive.
• Decrease Screen Space Reflection sampling.
• More than one camera rendering the scene kills the performence complety.
• Realtime reflections are very heavy. I never can use reflection cubemaps. Only in rare situations I use one single planar reflection probe. But it also just works with heavily stripping out post processing and rendering layers.
• Avoid too many realtime shadows.
• If you also use Enlighten with HDRP: Well, the same old rules for Enlighten apply. But there is very long and good tutorial from Unity about how to deal with it.
• Avoid high quality volumetric lighting. High quality only slighty improves the image but will cost too much fps. It’s not worth it. Instead apply the hidden option “Filter” under a light component. You have to click the cog icon to expand that option.
• Consider using GPU Skinning if you have a lot of animations and complex rigs. But from my experience GPU Skinning is almost always the better option.
• Reuse the materials per object and use texture atlas techniques where you can.
• Do you need always 4k textures?
• Do you need tesselation everywhere?
• Is your realtime shadow cascade range too high?
• Must every tiny and unimportant object cast shadows in your scene?
• Consider favour spot lights over point lights. Not every light bulb needs a realtime point light with realtime shadows.
• Are you using mutilthreading? There are animation C# jobs you could use. For example once I used a C# job to multithread the animation of a water surface (Gerstner waves).

One thing I never tried myself is DOTS and the hybrid rendering. With heavy mesh instancing you could also gain performence. But it is not production ready.

[valarnur]

My first game actually used HDRP when it was still in preview. It was very painful to work with it back then, but I managed it. The point is: Our scenario was photorealistic with a lot of realtime point lights casting realtime shadows. We also used Enlighten, means dynamic realtime GI. With my RTX 2060 and Intel i7-9650H, I get roughly 60 fps. But on our map we have some small areas where too much shadows overlapping, means when the player goes there, the fps is about 30.

How many lights on scene did you limit yourself with to keep such performance?

[Lorodion]

I’ve got the same issue as OP. I’ve got a Unity terrain of size 1000 with the MicroSplat shader applied (that’s the only geometry in the scene).
Now this scene gives me ~130 FPS with the built-in renderer (default graphic settings, in editor) and ~70 FPS when recreating the same terrain in a new HDRP project (Unity 2019.3.8f1 & HDRP 7.3.1) with MicroSplat HDRP.
I’m running this on my laptop which is i7 6700HQ, GTX 970M GDDR5 6GB and 32GB DDR4.
I was also assuming my laptop wasn’t next-gen enough, apparently I’m wrong
I’ve played around with the HDRP render settings and the camera and there’s no real difference in FPS.
Of course it could just be that MicroSplat is badly optimized for HDRP.
When looking in the profiler RenderPipelineManager.DoRenderLoop_Internal() uses 30-60% of the main thread when the game is running, with the one and only camera staying still and basically no custom scripts on.

[Bordeaux_Fox]

@valarus

How many lights on scene did you limit yourself with to keep such performance?

I used deferred rendering. So it’s performent to have a lot of light sources as long the radius is quite small.
I used a very short shadow distance like 20 to 30m. It worked because the map had a lot of rooms and L shaped turns. So you would not see many lights at a very huge distance.

[valarnur]

@Bordeaux_Fox

So you would not see many lights at a very huge distance.

I noticed this too.

Is there a way to increase draw distance of the lights ?

[RoughSpaghetti3211]

I’m having the same issues, feeling very frustrated.

[RoughSpaghetti3211]

@hippocoder

No, it’s very smooth on an AMD card from late 2014, so you will both have to file bug reports or take a much closer look at where your CPU time is being spent.

I get you have slowdowns but I spent 2 years on HDRP solid (almost daily) and tested it with a bunch of GPUs including a 980, which is easily equivalent to the OP’s card. And it flew, really flew. 200FPS+ on busy scenes.

So the assumption it’s all next gen is totally wrong. It’s designed for current gen consoles (the originals, not the refresh) and can scale to next gen with RT.

You guys are probably doing bad dev practises. It can be slow if used badly or you assume you can do the same practises as built in. For a start design out multiple cameras. These things do totally different things in HDRP. Each camera (by default) does a huge amount of up-front optimisation work to absorb larger workflows later.

You can’t just stack em and leave em (if that’s a thing being done).

I get I probably sound harsh, but how else will you stop assuming and start digging? Provide more info and better answers can be had.

Do we have an official best practice guide for HDRP. I would love to solve where this performance issues could be coming from

[tuinal]

To OP - 25k batches is a lot of batching work, which I’m not 100% is the cause, but it’s a high number. One of the most important things to do in general is merge meshes (either in runtime code or a modelling package), since more meshes = more batching work for the CPU. It is generally well-worth having big meshes that result in coarser occlusion culling, than many small meshes that all need to be set up for rendering by the CPU.

Some additional tips, and some gripes with HDRP:

Very important to find the ‘light distance’ and ‘shadow distance’, and ‘reflection probe’ distance options hidden in the cog icons. By default they’re set to effectively infinity. Since lights & probes don’t get culled properly, this means unless you fix a distance (usually by gauging if the player will notice or be able to see it), every light & probe in your scene is rendering by default, as well as every shadow, killing performance.

Planar / realtime reflection probes are not remotely performant and for tech demos only, or tiny rooms with a mirror (and not much else), and need a script killing the probe if they player leaves the area.

In general (main gripes here); real time shadows are utter framerate killers. Realistically if you have an ‘average’ complex scene (say 1m tris), one or two real time shadow sources are your limit in any given frame, maybe 3-4 if you dial down the resolution to pixel-art levels. This results in a lot of awkwardness, since a light behind a wall that’s not casting shadows will have it’s volumetrics and light bleed through the wall. So you end up having to design the whole level to accomodate the renderer to a fairly extreme degree.

This should mean you fall back to baked Shadowmasks, but these seem to have terrible performance overheads too, so the reality is you often need to fall back to baked lights with only 1-2 real time, shadow casting lights per area, and maybe 1-2 real time, non-shadow casting lights, carefully set up to cover the issues with baked, like the lack of specularity.

The final big issue is that whilst the GPU version eased the pain, Unity’s lightmapping is still awful; with a lethal combination of unpredictable, buggy, mediocre results that look nothing like the diffuse realtime render, and baffling sliders that need a lot of tuning against excruciating bake times (and when working/tuning creatively, even 10 mins is excruciating). This and related bugs like lights randomly switching off and on ignoring their mode. I’m sure there’s a complex technical reason why the beautiful realtime shadows can’t just be stuck into a lightmap, but it’s annoying they can’t (and changing them to ‘on enable’ from ‘realtime’ has little performance difference).

The conclusion I’ve reached with HDRP is if you’re making a beautiful RT render of an object, or small locale, e.g. for a portfolio/archvis/tech demo, with minimal or controlled camera movement - it’s great. If you’re expecting to make an actual game (or reasonably scaled level), where things like handling a light on the far side of a wall without it bleeding-through and need to use and manage large numbers of lights/probes/shadows, it’s very hard to stand HDRP next to Unreal and find reasons to argue in favor of HDRP.

[MajorParts]

So, multiple cameras…you can’t just stack em and leave em…what do you do then?

[ftejada]

Hi!!! I just answered in another forum thread related to this topic. It opened a long time ago and in order not to repeat myself I leave the link …
HD RP vs Built-In Pipeline Performance comparison page-6#post-5983316

I personally think the same as @tuinal and HDRP cannot currently be used for projects with somewhat large scenes … unless they are quite empty … needless to say if you have day / night cycles with scenes where there is a 300m ~ 500m field of view in front of you … puff …
There are a lot of things that kill performance too much with HDRP. But it seems to me that the problem comes from how Unity works the part of the cpu. If I am wrong, someone will correct me, but I think that almost all the processes that Unity does on the cpu do not take advantage of all the threads of the processor and that could be the bottleneck.

Someone with experience could provide information and data if I am wrong?

Cheers

[jacodavis]

@Bordeaux_Fox

I just went quickly over all the post in this thread.

From my experience: I already made two 3D games with HDRP.
My first game actually used HDRP when it was still in preview. It was very painful to work with it back then, but I managed it. The point is: Our scenario was photorealistic with a lot of realtime point lights casting realtime shadows. We also used Enlighten, means dynamic realtime GI. With my RTX 2060 and Intel i7-9650H, I get roughly 60 fps. But on our map we have some small areas where too much shadows overlapping, means when the player goes there, the fps is about 30.

My second game, which is in a more stylized appearence used the new HDRP without Enlighten. The setup is not as heavy as the other game. Again same specs. It runs with about 60 to 90 fps (depening what is going on). Very heavy of enemy animations and high quality physics. That’s the actual bottleneck of the game.

General tips what I’m learned from HDRP, but actually it applies to like every other engine:

• Choose the quality of post-processing effects based on your fps budget. You can easily kill the games performence with Depth of Field sampling a 1:1 image. So use half or quarter size.
• High quality contact shadows are also very expensive.
• Decrease Screen Space Reflection sampling.
• More than one camera rendering the scene kills the performence complety.
• Realtime reflections are very heavy. I never can use reflection cubemaps. Only in rare situations I use one single planar reflection probe. But it also just works with heavily stripping out post processing and rendering layers.
• Avoid too many realtime shadows.
• If you also use Enlighten with HDRP: Well, the same old rules for Enlighten apply. But there is very long and good tutorial from Unity about how to deal with it.
• Avoid high quality volumetric lighting. High quality only slighty improves the image but will cost too much fps. It’s not worth it. Instead apply the hidden option “Filter” under a light component. You have to click the cog icon to expand that option.
• Consider using GPU Skinning if you have a lot of animations and complex rigs. But from my experience GPU Skinning is almost always the better option.
• Reuse the materials per object and use texture atlas techniques where you can.
• Do you need always 4k textures?
• Do you need tesselation everywhere?
• Is your realtime shadow cascade range too high?
• Must every tiny and unimportant object cast shadows in your scene?
• Consider favour spot lights over point lights. Not every light bulb needs a realtime point light with realtime shadows.
• Are you using mutilthreading? There are animation C# jobs you could use. For example once I used a C# job to multithread the animation of a water surface (Gerstner waves).

One thing I never tried myself is DOTS and the hybrid rendering. With heavy mesh instancing you could also gain performence. But it is not production ready.

Simply put, HDRP is a piece of SH#T , why bother using it if you need to change all these settings. I get Much higher fps on the standard pipeline. If you want volumetric lights just use Aura (free)