HDRP Rendering paths and new features' performance characteristics

It's fairly common knowledge in graphics circles by now that Deferred rendering is great for many lights performance-wise and Forward is great for transparency and MSAA. However Unity's new HDRP Forward path has implemented tiled clustering to speed up Forward path's performance in heavily lit scenes.

How do all these modern features translate to real world performance on recent desktop GPUs? How should you make the pick between specifically Unity's HDRP Forward and Deferred paths? How many lights is too much for tiled forward? Is the old hybrid approach where transparent objects are rendered afterwards with forward rendering still a viable solution performance-wise?

Most of the recent discussion seems to be centered about LWRP vs HDRP and there seems to be little discussion about the recommended use of the new technologies in HDRP. Many of the features in HDRP have questionable or hard to determine performance characteristics and it's difficult to estimate their impact on a complete scene. Like should I be culling light volumetrics myself in code depending on their distance to camera? Are post processing volumes performant in determining the camera blending even with hundreds of volumes? What the hell is "Static Lighting Sky" and is it baking my scene in realtime all the time? How do vague features like subsurface scattering or transmission affect performance? Etc..

The standard answer here is "Just profile it", but since the use of these features and paths is usually determined before the game is in production phase and they're used to explore possible artstyles, it'd be useful to have ballparks for performance characteristics.

I'd be interested to hear discussion about the reasoning process devs should go through when selecting between Forward and Deferred rendering technologies in HDRP, and some recommended use cases and discussion about the newer graphics features' performance.

 

https://github.com/Unity-Technologies/ScriptableRenderPipeline/wiki/Forward-And-Deferred-Rendering

This has some explanation, but it's general because of how game-specific this stuff is.

Unfortunately you cannot have a table that's specific because game A may overlap a lot of lights and game B might not, and both might use forward. Both may have a different amount of lights in range, fade settings, shadow settings and more. Light types have a bigger impact on perf, but HDRP has a lot of options to manage light performance, and that's kind of more important. If I got my calculator out I would gently suggest there's probably around Mathf.Infinity combinations.

So really, your question to ask for more depth to the performance characteristics is a hard one to answer, but I'm sorry it can't be more than general purpose. With experience you will come to know what is a good idea:

- use few lights as possible
- don't light huge meshes with lots of lights (break up meshes)
- don't let triangles get too small
- test depth prepass on/off

Etc... mostly it's about testing the game with on/off. The beauty of HDRP is it's REALLY easy to test this on/off scenario.

The rest, you will need to act conservatively anyway. This means manage all your lights regardless of pipeline. Manage their falloff, fade ranges etc manually. Manage everything.

Where to begin? if it's forward vs deferred it's definitely as dumb as saying: foward for quality and deferred for lots of lights!

(I'm currently using forward as the framerate doesn't really change for me switching, indicating that I'm not light-bound).


The performance is extremely good so far, regardless of pipeline. It kind of helps you avoid the worst with how it fits together - the UI warns of common issues.

I welcome further discussion on this by others as I want to know more myself, so please don't think I'm shutting anyone down here, just broadly sharing my experience.

 

Is that really true? I'm not too familiar with the implementation specifics of the HDRP forward renderer, but the whole point of using tiled or clustered rendering is to decouple the lights from the geometry.
The LWRP still does per-object light culling so breaking up mesh renderers spatially can be a good idea (up to a point), but that really shouldn't be an issue with any type of forward+ or deferred. Forward+ just discretizes the light culling volumes to clusters or tiles so it will always be somewhat less efficient that the kind of tight bounding volumes you can get in deferred, but they should both handle lots of lights way better than traditional forward (i.e. LWRP).

 

Yes objects are still shaded in one pass, so you're correct it decouples it from geo. I think it's more paranoia than anything else making me recommend a still-optimised approach or at least to think about it.