HD RP vs Built-In Pipeline Performance comparison

I agree that Unity has some graphics quality disadvantages, but it is a very well presented video with a lot of useful information and a great looking result. I think a lot of people will find it very useful, and videos like this go a long way toward making new features approachable.

 

The real life values are great and all, but it's not that practical for game development, let's say that you want a sunny day (~100000 lux) and you want to have a point or spotlight in your scene, you'll have to put it to a ridiculous value to see any result, while this might be physically accurate it's not very creatively satisfactory.
In my projects I use the directional light between 10-20, a dynamic sky with a exposure of 1 and I tend to get a good usability from it (there's still the nagging on my head saying "you shouldn't be using it like this").

 

It honestly depends what your motives are though. You seem to have a good grasp on physically accurate lights and materials and that is precisely the point of HDRP, if it is not, i.e if you don't care for physically based accuracy then you can pretty much discard all standard procedures and do what you wish. Or use another pipeline

 

luckily it exceeds the level of realism of the other other engines.

 

On what basis do you say this?
If you take a look at projects with AAA graphic quality and use of integrated shaders, Unity it is far from realistic.

There are many jobs where Unity performs better, but in those cases non-integrated shaders and others elements are used.

Aside from CRS2 (which uses proprietary shaders) and some other famous games, the rest of the developers prefer other engines. Why?

I agree that Unity can give great results, but to bring out the best it requires a lot of work and in fact if you take a look around you don't find many excellent jobs.

Without considering that if you try to make a game with HDRP you regret being born and having chosen to develop video games, it is described as a well integrated and consolidated system but still has a lot of big problems.

 

Hi everyone!! I have been following this thread since it was created. And I didn't want to comment until HDRP was preview.



There are opinions that I did not see correct by some users, whom I respect a lot, about the creator of this thread. It has been argued that HDRP was still in very early stages, also that it could not be compared with simple scenes since it has default costs and that if you fill a scene very much, it is when you see that HDRP manages to hold without losing as much performance as the channel of Unity standard rendering, etc, etc..
The case that during these two years aprox. everything has seemed like what is usually said of "the chronicle of an announced death" ...
And what I mean is that from the beginning you could see that there were things that "didn't quite fit". And it seems that we have felt more comfortable looking the other way, defending HDRP because it was not ready yet.

I have been doing all kinds of tests and scenes for 4 months, simple and complex. And my opinion right now regarding HDRP is that the performance that is achieved is unfortunate and still has many problems.

You practically can't use real-time reflections with (refletcionProbes or PlanarReflection). Not even one per scene. The performance drops a lot.

HDRP greatly penalizes performance if you have more than one camera on stage. Although it has all the features (PostProcessing, fog, trasparentObject, etc, etc, etc, etc, etc), disabled.

You cannot put a lot of vegetation on a terrain because the performance drops quickly and it is impossible to reach 60 fps. Not even with assets like VegetationStudioPro or GPU Instancer.

I have the same scenes in standard built-in that can support 70 ~ 80fps without any problem and with a reflectionProbe realtime, updating in each frame ...

What is happening with HDRP ?. I imagine that HDRP can no longer be said to be in early development..
What about what they said in Unity that HDRP had better performance than the built-in pipe? Under what conditions does this occur?

I understand it can consume more, because it does many calculations of lighting, shaders, etc, etc, etc and that it is supposed that with that payment of performance, better photorealism is obtained for our graphics, but so much ?. It is impossible to work in HDRP and achieve decent and stable performance? Not even at stable 30fps with open world scenes and somewhat loaded with vegetation, an ocean and nothing else ... Imagine when you put everything else that a video game must carry ... Puff I do not even want to imagine it.


I have done tests on two PCs for my compilations of the scenes that I indicate, (i7 and GTX 1660ti) and (i9 and RTX 2070). In both the performance is very poor. It is true that the pc (i9, RTX 2070) is somewhat better, but not much and I can't even get a stable rate of 45fps ...
Really?.
Surely someone may think that surely I will not be optimizing the scene well and that the problem comes from me. Obviously it is the opinion of each one and it is very respectable, but I think that HDRP has a serious problem at the moment with the performance for many reasons.
It can be used to make small scenes, but for complete games with very complex scenes, in my opinion, it cannot be used.
And the truth is that it is a great shame for me, because I like the results with HDRP (although it takes a lot of work to get those results for various reasons).
But for the first time in these 7 years that I have been using Unity it is the first time that I am considering using Unreal


I am not an expert, but all the bottlenecks that are generated always seem to come from the CPU, if you have a decent graphic card ... Why? Perhaps Unity internally still does not use all the threads of the processor to do all those heavy calculations that HDRP needs? In the profile you see some things that go to other threads "Supposedly" ... but I think the vast majority follow the main thread ... And I warn that I am not an expert analyzing the profiler, so if I am wrong I hope that someone will correct me with data
Could someone with more experience report here, if what I say is true? Any info would be welcome.

I asked something similar on the Unity forum and no one answered.

Anyway ... I think HDRP is still not usable because of the bad performance that is obtained.

Cheers

 

a thing called 'logic'.

To claim 'HDRP does not reach the level of realism of other engines' is equivalent to claiming that HDRP is the least realistic engine there is.

 

It does sound like a poor performance of executing scene analysis - CPU sends render commands (draw calls) to GPU every frame. It needs to check which meshes are in camera frustum, not culled by distance, other geometry or specific solutions like culling volumes. Lots of stuff and conditions to process. Then a separate draw call is issued for every separate mesh.

And finally sending thousands of draw call costs much, mostly on the CPU side. Especially when using older graphic APIs like DX 11 where communication between CPU and GPU goes through a driver. It's so important that the major feature of every modern APIs (DX 12, Metal, Vulkan) is that the driver layer is minimal, removing its overhead. But now the engine needs to implement a huge part of communication between CPU to GPU, although now it can be properly optimized.

I wonder how the foliage is placed in Unity then? Even with tools you mentioned?
Hundreds and thousands of separate foliage meshes would kill the performance of any engine.

For example, Unreal comes with a Foliage tool allowing to place foliage as optimized instanced static mesh. All instances of mesh on level costs only a single draw call. And this allows for further optimization like distance culling. It's common uses for grass, bushes, tree. Often used to place groups of small actors like stones.
All these meshes are batched statically. UE4 now has dynamic instance batching, but it has limits. Framerate died when I tested dynamic batching of 40K cubes with it

 

I think he is poking fun at the "other engines" which is an euphemism for Unreal Engine/Cry engine, meanwhile Unity is quite capable for 3d rendering when compared to the vast majority of commercial engines like Source, Godot, Panda3D, Game Guru, Torque, Ogre3D etc etc. But we all know that the comparisons are always against UE.
EDIT: Realtime Reflection probes do really tank performance in HDRP (to an unusable degree).

 

Thanks for the answer @MothDoctor !!.

I don't know how to answer this question, but these third-party tools are supposed to be the best Unity has at managing these kinds of performance issues ...

https://assetstore.unity.com/packages/tools/utilities/gpu-instancer-117566

https://assetstore.unity.com/packages/tools/terrain/vegetation-studio-pro-131835
Even VS Pro uses JobSystem ...


On the other hand you have given a very good info about modern Apis, maybe I could try testing these same scenes to see if the performance improves under Dx12 or Vulkan
So I will do some tests to see how it goes ...

If you have more info I would ask you to share it because I am very very interested in getting to see that my opinion is wrong

Cheers

 

They killed my performance in-editor too. I converted a project over and it seems like they get updated in the editor view now, so my frame rate died.

Also, it seems like they still take bad images compared to ReflectorProbe.

 

Hi everyone!!! @MothDoctor I have done some testing and running the play mode under Dx12 worsens performance for me and vulkan causes Unity to crash.

I have not checked it in compilation given the time I need to compile it ... But these days I will do a build under Dx12 to see if it improves something ...

On the other hand, I have been talking to the developer of VSpro and he tells me that Unity has not provided an api to be able to occlude culling for the job system ... and it seems to me that there is not even an ETA for this ...

So all the objects (including vegetation), which are behind a large mountain, will continue to be drawn, with the loss of performance that this means as can be seen in the video.

I have also tried the native Unity OclussionCulling and I see that the same problem occurs and everything that is behind a mountain where the camera looks, keeps drawing and does not occlude any culling ...

This problem also occurs with GPU Instancer ...
I'm only talking about HDRP with Unity 2019.4. In other versions, in URP and in built-in I don't know if it happens.

My feeling is that Unity is making it harder and harder to work properly and there are things that are already beginning to touch the dramatic.

Cheers

 

OK, that explains a lot.
That's a bad thing that something like this happens in the renderer marked as production-ready. The good news is once it is addressed, it should fix most of performance regression in the new pipeline...

Not very surprising, given that new APIs are in preview still, right?
And performance might differ between video card vendors. For instance, when Epic enabled DX 12 for first tests in Fortnite, people got up dozens of frames more on AMD cards, but dozens of frames less on Nvidia

 

See if the new Apis improve or Unity improves in how it communicates with the new Apis ... to know what it can be ....

I have done more tests with the profiler and from what little I have in the scene of the last video and the photos from yesterday, I see that the vast majority runs on the main thread saturating it.
Unity seems like, (when you install the job system package etc etc) that natively all HDRP heavy load and other processes DOES NOT use JobSystem next to nothing.


I know that I am inside the editor analyzing in play mode, but ignoring the sections of "EditorLoops" it can be seen, or it seems to me from my ignorance, that Unity almost does NOT use multithreading to divide the load of all its internal HDRP processes ... and the graphicCard spends most of the time dragging its belly ... (If I'm misinterpreting the Profiler data, please correct me). By the way I have followed this video that Unity recently uploaded, to interpret the profiler:

And there may be the big problem of HDRP performance compared to standard pipe. That is, if HDRP needs more power than built-in and on top of that you don't take advantage of the multithreading of modern cpus, then there may be the problem. What surprises me is and makes me doubt that perhaps there is another underlying problem is that Unity in two years has not made Unity take advantage of multithreading with JobSystem for their internal rendering processes.

Maybe I'm making a mistake and I'm being unfair, but after about 2 years I thought Unity would already have its engine working to take advantage of all the cpu threads ... and it doesn't seem that way to me.

Then there is something I do not understand in the Profiler data, (to see if anyone can contribute info),
Why does the PlayerLoop process run twice?

Cheers

 

In Player Settings you can find a "Use Graphics Jobs" option. I don't know if it works with HDRP, but it was designed to at least jobify the built-in renderer.

And on some platforms you also find a "Use multi threaded rendering" option. Again, no idea if it still works with HDRP.

 

I am going to try... Thanks

 

@Peter77 Hi again!
I have looked at what you said and Graphics Jobs is marked by default, since I have it activated and I did not activate it manually.
On the other hand, the option of "Use multi threaded rendering" doesn't seem to be for PC because I can't find it ...

So we did not continue at the same point we were at.

Cheers

 

I wanted to show you the result I got for an ultra light WEBGL version of my game.

Configuration:
→ Standard Shaders for vehicles only
→ No post processing
→ No LWRP
→ Shadows lights disabled and simulated with the projector (Blob Shadows)
→ Color Space: Gamma
→ No HDR
→ No Occlusion
→ MSAA Quality setting based


Clearly, as you can see, the ground is naked and with low quality texture (256x256).

Vehicles also have low quality textures (512x512) but what strikes me is that in "some situations" the car render effect is extraordinary as in this screenshoot that I captured.

Game setting in Ultra (40fps on browser in full screen):





The graphics / performance balance is really high.
This makes me think that with a little work and a few tricks you can do great things even avoiding HDRP and LWRP.

Or at least it's worth studying over it.

Link: https://www.gamearter.com/game/evo-f4/
.

 

Today I continued to test using the Color Space "Gamma" but with a 1024x1024 terrain texture.

Maybe it's my eye that is seeing badly but it seems to me that the result is quite realistic despite the fact that I have put the settings that should penalize the graphics in favor of performance.

What do you think?

The game performances are even superior to the LWRP.



.

 

The devil is in the details here. But in a large complex game we are rendering a lot of vegetation plus the Crest ocean renderer plus a bunch of structures and dozens of characters, and we stay over 80fps. That's on an older gpu gtx 1080. We can easily bury that gpu if we crank up vegetation density, without HDRP otherwise getting too expensive on the main thread.

This is with pretty much all features enabled at medium to high quality, not the super high super expensive. Realistic settings like reflection but updated periodically or only when actually needed. Lightmap settings appropriate, etc..

HDRP is expensive in terms of main thread cost no denying that, and they could make that better. But our rendering performance improved quite a bit when we moved to HDRP a couple of months back now.

But we have proper LOD/billboards and fairly well optimized geometry throughout also.

Also Occlusion culling is nice but really shouldn't be an issue with good LOD and billboards and a reasonable clipping plane.

 

WebGL is expected to have near desktop graphics and performance since WebAssembly was implemented a few years ago. Too bad there is no

Example Game 1
Example Game 2

 

Unfortunately, the WEBGL platform still has a lot of work to do before it reaches desktop graphics and performance.
Not to mention that when exporting the project several things have to be readjusted because there are always differences between what you see in the editor from the compiled result.
Not to mention the loop sounds always create an annoying cut.

It was a better time when using the webplayer's NPAPI plugin.

 

For me it ran quite poorly, unplayable I'd say. I didn't touch any of the settings, it defaulted to "medium". I already saw jarring microstutter in the camera animation at the start. While driving around I had stutters that felt like up to half a second, maybe more. The streets were pure-black, dunno if that's expected or not, but it looked wrong.

I have a gtx 1060, old i7 cpu, tried it in windowed mode (so slightly less than 1920 x 1200 px resolution) in the 64 bit portable version of Waterfox 2020.06.

I hope any of that is useful information to you.

 

Thank you,
This is bad news, more or less you have my same PC configuration, only that I have an nvidia gtx 1050.
The roads should have a asphalt texture.

I will try to investigate.

 

There shouldn't be many visual differences from Built-in/URP. Make sure you are on Edit > Graphics Emulation > WebGL 2, and you can still use Linear lighting instead of Gamma, and post-processing.

 

Hi @snacktime !!! Could you show some screenshots or gameplay of your scenes and Profiler? It would be greatly appreciated to get an idea of the type of scene you are referring to.

In the tests I have done I have configured everything ... (Lods for the vegetation, last Lod are 3 overlapping quads, OclussionCulling of the entire scene, tools that help with performance such as GPU Instancer or VS Pro, and many more tests) .
The performance is still not a good thing and I can't get to 60 fps ...

The truth is that by testing I see that I can't keep 60fps stable with the empty scene, the terrain with only two textures, the ocean (Crest HDRP) and a Planar reflection ...

So with that said, if I can't get stable 60fps with an almost empty scene and no vegetation, (only Crest, a terrain and a planar reflection), I'm not sure if the problem comes from me due to bad optimization ...
When in standard built-in with that same scene 70 ~ 80fps stable ...

Regards

 

"Empty scene", and "just terrain + ocean + planar reflection" is a huuuuuge difference. You're probably using the built-in terrain component too, right? Many Unity versions ago, back when I worked on something with an RTS-ish camera perspective, I decided through testing that for my usecase the terrain component is hot garbage performance-wise and just dropped a 1~million poly mesh in there because it was way faster than the CPU overhead that the terrain component creates. And if you're CPU limited to begin with, afaik occlusion culling might make it worse, because that's a CPU computation to prevent a GPU computation.

 

I have a weak card, i expected that to run like potato, but even full window size in the bowser, i get 59-59 on medium and near 30 fps in ultra, my card is a gt 705 ... i do have a i7 6700k

 

Thanks for trying it.
It is very helpful to have feedback.

 

Even the ocean is not to be underestimated, the constant calculation of the tessellation and the reflections of the lights especially in HRDP is very heavy.

 

Game isn't ready for showing any public screens atm.

Reflection probes and planar reflection are expensive. Hence my comment about periodic updates on those.

You need to start with a baseline of close to nothing and add things in one at a time, so you know what costs what. You really have to do this at a granular level, like test different HDRP/lightmap settings with specific features like terrain and ocean enabled/disabled.

Also get used to not using fps to measure stuff. Fps is a high level indicator that tells you nothing about what specifically is using up resources. You need to measure the impact of individual things in the profiler in ms.

Once you know what is expensive then you can move on to how can I improve X, where X is something very specific.

We have scenes per major feature so we know what is the performance impact of just one thing. We know with a lot of granularity what costs what and why. This takes a lot of time and there is no shortcut.

Basically you just need to put in the time to debug it correctly.

 

yes, you can study as much as you want but in the end the only thing that pays off is to test everything a little at a time ... because each project has different characteristics and there is no universal guideline.

 

@Martin_H I understand what you say and I share it ... and it is true that I use the default terrain of Unity. But I also use it in the built-in to compare the performance of built-in vs HDRP as accurately as possible ...

I just meant that ...

@ciorbyn I know, but as I said in built-in I have the same things and the performance is much higher.

As I said a few days ago in the thread, I know that HDRP has inherited costs for the calculations it makes in order to have "photorealism", but currently the cost seems excessive to me ... too excessive ... it just doesn't seem to be usable for now open worlds loaded with vegetation and other things that are required ...

As a cpu I have an i7 (from a few years ago) but it is not a short cpu. On the other hand I have also tried some builds on an i9 with an rtx 2070 ... And if with that you can no longer have decent performance, it seems to me that I am not very wrong when I say that it seems that HDRP still has a performance problem in several areas, such as reflections ... (which by the way, does not matter how you configure them, you will not be able to avoid the great loss of performance) ...

@snacktime
I know and I am at it ... as I said in another message, I do not take the fps as a reference, I am more interested in the Profiler data, (although for simplicity and for people to understand it better I talk about the fps in the forum ).

Reflections Probes know they come at a cost, but in HDRP they just can't be used in real time because of the huge performance penalty ...
You can try updating them in some specific frames instead of all, but anyway in that frame in which it is updated it will consume a lot.
You could try updating the reflectionProbe or the PlanarReflection in several frames ... But HDRP I think it already does it by default ... Maybe you can extend those frames that take time to update by script? This I don't know anymore ...

But I repeat ... My HDRP vs Standard tests are made to maintain as much as possible the same characteristics and content of the scene.
I think that it is useless to do the tests if in standard I have a reflectionProbe in realtime each frame with 60fps and in HDRP I get 60fps but without having any reflectionProbe in realtime ...
I think those tests are not adequate.

Another of the many things that I have done in the multitude of tests that I did, is what you say ... I have been adding little by little, deactivating and activating features, etc. to identify aspects that penalize performance in HDRP too much

And as I have said the worst friends of HDRP currently are things like having more than one camera, planar reflections or reflectionProbes, Reprojection in volumetric fog, and some other things).
But aside from these characteristics that can greatly penalize performance, it seems that the HDRP cycle itself has high performance costs as soon as you start to fill the scene ... And I say this because of Profiler data, not fps ...
And things that have a high budget to reach 16ms almost always seem to be related to internal aspects of the HDRP cycle ...
That is, in which I can do nothing except leave the scene more empty.

One thing that I have not tried due to lack of time, but I will, and that gave me the idea @MartinTilo , with which I am very grateful for your attention, is to put all the prefabs and objects to be treated with DOTS and see If this brings me closer to the 16ms budget in Profiler

I have seen that in HDRP 8.x.x they have achieved improvements of up to 25% ~ 50% in the preparation of the illumination of the objects for GPU, or something similar ... I do not remember it well ...

Let's see how this improves performance. I have not had time to try it yet, but it is one of the tests that I will do as soon as possible with the same scenes that I am testing now ... and compare ...

Regards

 

I probably should have mentioned we are on the bleeding edge with SRP. Mostly because we use DOTS so that forces it to some extent.

DOTS only improves rendering performance if you use Hybrid Renderer V2, which requires a preview release of HDRP 9.x. I tested it quickly just wanted to see if there was a significant difference between a bunch of static gameobjects and HR. Not much. Also HR V2 is a bugfest atm.

 

@snacktime Forgive my clumsiness but English is not my native language and your message has not been clear to me ...

Do you tell me that with DOTS performance improves a lot or not?
I'm sorry I didn't understand you

 

DOTS hybrid renderer V2 which requires an early preview of HDRP 9.x is better. How much depends on the context. It varies from a small amount to a lot. It does async gpu uploads, persists data on the gpu uses SRP batcher and has job based culling with gpu culling hooks to come at some point.

It's also extremely buggy right now with some basic stuff still not in like indirect lighting. The whole thing right now is part awesome part clusterfuck. If you are already using DOTS generally in a game that won't release for 10+ months then ya it's probably what you want to use. Otherwise probably not.

 

I get it. Now it has become clearer to me.
Thank you very much. I'll continue testing and when Unity 2020 comes out of beta in a few weeks (I guess), I'll start migrating and testing DOTS.

Regards

 

Regarding DOTS, keep in mind Unity is planning to hide preview packages including some DOTS packages in Unity 2020. You'll need to dig more to find them in Unity 2020. At this point, it looks like they simply moved the "Show Preview Packages" option into the project settings.
https://forum.unity.com/threads/visibility-changes-for-preview-packages-in-2020-1.910880/

 

It is true, I was watching some videos and I realized that in Unity 2020 it changes. Thanks for the info...

 

Spoiler: sorry

Hello, i am ALIyerEdon (Lighting Box 2) user
I apologize
I was sick several months ago and my account was in the hands of my young student
He has advertised incorrectly in this topic (Post)
Because he does not know much about the rules of the forum
And he thought he could advertise on any topic I created

Unity 2020.2

Built In 4K :90 fps
Built In 1080 : 300 fps

Built In 4K Deferred :65 fps
Built In 1080 Deferred :260 fps

HD RP 4K : 21 fps
HD RP 1080 : 65 fps

URP 4K : 110 fps
URP 1080 : 270 fps


3 images on the next post

 

3 Images ...

 

Do you have any profile data

 

I do not understand what you mean by data profile.
If you mean settings:

HDRP is the default unity sample when creating empty project
URP is same (default)
Built in has been converted materials in URP sample and added post effects personally, then switched to the deferred

note: i a bit customized post effect settings (color grading and bloom) to have same graphics looks in all pipelines,The default settings were not the same

 

https://docs.unity3d.com/Manual/ProfilerWindow.html

 

Some screenshots from Both HD and Built In pipeline: (2 years old):
Built In:

HD:

 

Built In vs URP with no shadows no effects everything has been disabled:



Only 1 directional Light

 

1 Directional Light + Shadows:

 

1 Directional Light + Shadows:
View attachment 712355
View attachment 712358

 

@MasterEdon Comparing render pipelines with a rather empty scene or a few boxes is totally nonsense! Who cares if FPS is 1200 or 700!

A real benchmark involves a lot of engine/scene elements as URP/HDRP may result lower FPS in a default scene but bring their power whenever the scene is full of objects, materials, effects... Or your posts may be considered as spam!

 

It has already been tested on Book of the Dead scene (same result ,30~50 % higher fps on Built in compare to HDRP)I will find its screenshots later in my pc and share them here
Now I wanted to test simpler scenes as well to see the base performance