HD RP vs Built-In Pipeline Performance comparison

Hi all

I want to share my performance comparison between HD RP and legacy :

Both are same in performance (color grading is a bit better in DH RP)

 

Moved from experimental preview forums as performance comparisons are quite useless this early in development. Thanks for understanding and in future check stickies for what kind of feedback Unity is looking for in the experimental forum

 

Try crancking up lot of lights with shadows, add volumetric effects (hd comes with, with default you are looking for some asset store package), try to change something internally in the renderer and you’ll see wich one is better.

 

a lot of lights is not an useful thing in realtime games. We just needs 1 to 4 realtime lights in most game styles (creating distance based light culling needs just an simple script)
I will try more samples when i had some free time

I'm not enemy for HD RP. i just want to compare everything

 

Does the global fog stop working on HD RP?

 

Not sure about what game are you refering, modern games uses more than 1-4 lights.
Deferred, Clustered, Forward+ and the likes was a necesity cause games needed lots of dynamic lights. HD renderer can handle 1000s dynamic lights btw.

 

Yes. You can use Volume script instead (applied in screen shot)

 

Sun + Spot light+ Player car (all other has been baked in most games)

 

The HD RP is still in early stages, though. What you compare now might not be accurate anymore, when the HD RP is stable...

 

It's stable now but it's not complete (needs more shaders,terrain,grass,tree ...)

 

HDRP is only in experimental/preview phase, it's not released and it is not bug free (stable) and it is not compatible with a lot of hardware yet. It would be false to presume otherwise. In future, the shader graph and more shaders are coming. For now, it's very much work in progress.

For a much more complete RP, check out the Lightweight. This perhaps will one day replace builtin for most people. It's fast, it's stable, has a shader graph and more features are being added over time.

 

Not all games uses that workflow, that is very specific to every game. You can find games with 0 dynamic lights and games with 100s dynamic of lights.

 

Stability can refer to both crashiness and API changes. I don't think it's quite there with either, and especially API rewrites could improve results a bit

 

The main problem in Lightweight or HDRP is that force us to leave a lot of shaders and image effects or tools :
Amplify Shader Editor
terrain shaders
Custom image effects

I think built-in pipeline must be available for lifetime (to support all projects from unity 1.x+)

I will try to test lights in the future

 

Sure, but it will lag behind in performance. HD uses compute, eventually Builtin won't be able to keep up.

Builtin has the benefit of being able to work on everything without re-authoring which is nice for some people.

 

Well, this is interesting - however it’s not ditching anything IMO and is feedback that can help the team finetune something.

Now I can see in the HDRP more batches while showing 0 shadowcasters.

More batches could imply the pipeline uses more complex shaders that can be more difficult to batch which could be understood as HDRP standard shader adds more features. If HDRP goal is to look better well that’s a trade off you can expect. If Unity was able to get HDRP run at the same or better performance than builtin then this would be the unique reason to get involved in this change.

But 0 shadowcasters? I wonder if the scene is correctly configured or if it’s just a beta issue.

 

The statistics window was not stable during screenshots. the fps was between 21-33 on both pipeline
So batching might be random and it's not too accurate

I just wanted to compare the approximate and show that both are almost the same
One user said before that HD RP is 3 times faster

 

Didn't the amplify guys tell us (in their thread) that they are working on supporting the same system that the shader graph is built upon?
ASE is (I think) not one of the tools that will be replaced.

 

ASM is based on surface shaders. In new pipelines we can use only HLSL or Compute shaders

 

It's not even beta. HDRP isn't that far yet that Unity needs a barrage of performance tests. What they need are people using HD in a non-essential manner for now to point out bugs, workflow issues etc... When it is stable and actually in beta and not experimental (it's all experimental workspace atm) then we can moan about perf and stuff. All things in good time cos half of it is missing.

Having said that, there isn't much on PS4 pro that matches book of the dead visually, and (under load, ie being stressed by an actual game) it holds up at 30fps native res. Naturally that Unity demo avoids other stresses typical of a running game, but it's a good start (right track).

 

Fair enough. I would have a few performance cases (scenes) for reference purpose that can be tested along development - I know, it’s a preview but it can be encouraging to know how your developments are going in term of speed for real scenes. Not to be left for the last week you know.

Also it might help achieve that 500ms max. Philosophy that Joachim announced.

 

I'm pretty sure they would have been considering performance as they went along with planning & development. I dont think its too early to talk about performance at all. Certainly its too early to talk about it conclusively in terms of the final system, but that doesnt make the broader discussion invalid. Having said that, I have assumed that Unity arent really ready to fully engage with this sort of HD pipeline feedback yet because for 2018.1 there was a thread specifically for Lightweight feedback, but no direct equivalent for HD.

 

On my test cases, both HD and LW beat default renderer in performance and build-in features. I don't have the numbers but it was by a very large marge and it's kinda expected, both HD/LW pipelines are modern, specially the HD with it's extensive compute shading use.
It will be just a matter of time for people to adopt it and forget about current pipeline.

 

Without numbers and screenshots it's not useful for users

 

Speak for yourself. I like detailed info but anecdotal evidence and general discussion is still of interest and useful too.

 

I had to drop a new test:

Cubes: 3642
Point Lights: 47

Camera on middle of the cubes:
HDRP : ~83 fps
Built-In without Light Culling : ~30 fps
Built-In with Light Culling : ~110 fps

Quality :





GIF:



Culling Script:

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class CullPerDistance : MonoBehaviour {
6.  
7.     // Use this for initialization
8.     Light l;
9.     public float updateInbterval = 0.3f;
10.     public float cullDistance = 300f;
11.     Camera c;
12.  
13.     void Start () {
14.         l = GetComponent<Light> ();
15.         c = GameObject.FindObjectOfType<Camera> ();
16.         StartCoroutine (UpdateLightsDistance ());
17.     }
18.  
19.     // Update is called once per frame
20.     IEnumerator UpdateLightsDistance () {
21.         while (true) {
22.             yield return new WaitForSeconds (updateInbterval);
23.             if (Vector3.Distance (transform.position, c.transform.position) > cullDistance)
24.                 l.shadows = LightShadows.None;
25.             else
26.                 l.shadows = LightShadows.Hard;
27.         }
28.     }
29. }
30.  

I will speak for everyone with detailed tests with long experience

 

Test projects
https://drive.google.com/file/d/1BZjEfN6LwWl4LKImH2QMS3qL-H5Iiu3A/view?usp=sharing
https://drive.google.com/file/d/1Qi2pAxx4wUUfbo_LRu-bcnFTC3Rz1a0u/view?usp=sharing

 

with post processing:
- Exactly same project and post profile (duplicated project) :

Unreal Engine vs Unity Built in (without culling) :

 

@aliyeredon2
HD pipeline computes more stuff in the backend. Newer lighting models, analytics functions, etc. Things that are absent in default pipeline. Plus, when you start to add more dynamic lights, you'll hit a bottleneck really fast with default pipeline.
Try to compare with LW pipeline, see which one is faster.

 

Do a build and check the frame rates from that. The editor probably takes a good chunk out of the performance.

 

GPU performance always is native. But CPU performance maybe a bit better on final built
But in this test, both are in Editor. It's not important

 

@aliyeredon2 ,
Built-in does have serious light limits hence the need for Pristine/Clustered rendering in HD pipeline.
If your game requires less than 8 dynamic lights active at once, LW pipeline will be more than enough, the rest can be baked right?
No matter what you do, LW will be way faster than default pipeline.

 

LW quality is a joke . It's not good for PC or WebGL

How many lights do you like to i test it ?

 

You aware you are comparing 3 different renderers for 3 different purposes and target hardware?
One for high end state of the art rendering (HD), one for low end hardware (LW) and one for in-between both of those (current pipeline).

 

I am not sure how one can compare apples, oranges and eggplants.

 

Yeah, this thread is...

I feel it dramatically misses the point of the LWRP

 

@aliyeredon2,
You can notice the ridiculous amount of drawcalls in the current pipeline (from your own test ~55K vs ~9K). This will probably won't make a difference in your boxed test scene but in a real-game scene where the CPU is used a lot more will make a huge difference. A scene full of boxes is not really a benchmark, the GPU is not even being used @10%. I think a better test will be using a real game scene (the one you used in your first post for example). Then from there test with few lights then add up to ~1000s lights.
Finally, both HD and LW aren't even finished and they already showing really good results.

 

I will make another test on first scene and "3D Game Kit" from asset store

I have used 7850 (~ps4 gpu) for testing performance
It's not a old GPU

Compare Left hand(Light weight), right hand (Built in) and upcoming third hand (HD RP) . I think the Right hand is in most humans is better
People are hoping they will be much better if they have a third hand
But in the tests I did (above), I think the right hand is always better

 

Six years. I have some hardware dating that far back (my dad is on an eight year old card) but while it may have some life left in it I don't think of anything that far back as being anything other than "old".

 

I bought it especially to have PS4 gpu power in few weeks ago
My 960 and 780 performance is same with higher resolution. From effects and compute side, all are fully featured from 7000 and GTX 400 series
7850 60fps 720p
960 60fps 1080p
780 50fps 4K

Currently the main problem is the post effects performance on high resolutions

 

So I think perhaps teams will choose:

* LW still if they want VR to run well, or mobile, or WebGL (if not now then eventually).

* Builtin has it's fans - hobbyists, people who need broad stable compatibility or existing projects with lots of assets.

* HD is for people with a big art budget. All that shininess won't help without things that take advantage of it. HD is also harder to use than both LW and builtin. Much harder asset authoring and understanding required. Naturally

So it is for these reasons I can't say one option is always best, but that's just me.

 

Yes, people always choose themselves

I just like to share the result of the comparisons

 

There is a lot of sense in this point, but I also think its possibly a bit easy to overstate this.

For example HD pipeline is not just about photogrammetry level visuals etc. A couple of performance reasons and a particular lighting feature might be enough to make someone choose this pipeline, even if a lot of their art assets dont go the extra mile to use every HD feature. Yes they must obviously achieve a basic level of compatibility and not look completely wrong or out of place, but I wont necessarily need an art budget thats an order of magnitude higher than it has been with the standard pipeline in the past.

There are also other new unity systems coming that may only target a particular pipeline, and it's important to factor this into pipeline choices we make. The most obvious example I can come up with now is the new GPU VFX system that will be in preview this summer. Not all that much has been said about it officially so far but when it was announced during the Roadmap talk at GDC (which is now finally on youtube, yay) it was said that this system targets the HD pipeline, so theres another reason people might chose that pipeline even if their art doesnt take advantage of the other stuff HD pipeline has to offer.

For now and a fair while longer many of the barriers I face as a very small entity wanting to use the HD pipeline are not directly related to art budget directly, although some do have a relation to it I suppose. They are all about time: Time for Unity to add certain basic core features to HD Pipeline (eg shadergraph), time for me to learn various aspects of the HD pipeline, time for 3rd parties to either support the pipeline themselves (or not), time for art assets designed with HD pipeline to appear (or not) etc.

 

What I like about this split pipeline philosophy is that LW pipeline won't drawback HD pipeline features (and vise-versa). Unity can have different rendering folks focusing 100% on specific features for both pipelines. You want speed = LW, you want high end features = HD. You can't afford to update your project now to any of those = Current pipeline.

 

Appreciate OPs effort on early testing.

Although I strongly disagree with that, I accept this bias from OPs art style.
True fairness is hardly find from individuals, but through discussion, we can achieve some fairness from an average of bias opinions.

I remember we have custom SRP for the rest.

 

Without being disrespectfull to the thread OP, what I saw here are mostly biased one-side tests.
For example, try re-creating Book of Dead with Default renderer with all it's graphical features and make it run 30fps on a PS4pro.
Good luck finding an volumetric lighting solution that doesn't duplicate light buffers and re-sample them outside shading passes. There's none. When you start patching and adding graphical features to default renderer it quicly become incredibly bandwith punishing and limiting.
Lastly, try running a game scene with 1000 visible lights on default renderer, see what happen.

 

In deferred rendering path you can use unlimited lights
Here you can see how built-in can handle 1000 lights without shadow problem with higher fps (shadows has been disabled for both renderers) :
Built-In:

HD RP :

 

IMO, he is not bias enough until the last test.
Bias is good thing in software testing, which always challenging the alternate path of use case.

Nice work, with your support, I believe HD would soon be stable

*Btw, keep an eye on your GPU temp, my friend. I have too many failed GPU by overheating, hate to see another good machine failing.

 

@ aliyeredon2
Would you mind sharing that test project? Im curious about your procedure.