Depth Priming Advantages?

I saw the new beta includes Depth Priming in URP which sounds like an amazing feature for me. Was somebody already able to test it and the impact it makes? I have a scene with a lot of overlaying geometry (stencil based) and from what I understand Depth Priming can really cut down the render times because it will do a depth pass first and then only shade the pixels that are on top. That should do a massive boost especially for VR games I guess, or do I misunderstand something and the depth prepass is eating up all the gained render time already?

 

We used to do force depth for different parts of the scene to optimize the rendering like this. We would even sort the triangles of some objects front to back (we had fixed camera angle). The win depends on a lot of things of course, but in the most dens areas of the scene we would get around 12% improvements. This should be even better, because it would apply to the whole scene and you wouldn't lose anything because of non-optimally sorted vertex buffers.

 

One question to concrete usage. Is it enough to simply activate it and the shaders automatically profit from it or do I need to adjust my own shaders explicitly? And are the default URP shaders taking advantage already?

 

The build in URP shaders are already supported and unless you are handwriting your shaders from scratch there should be nothing special you should need to worry about. They just need a depth pass and ShaderGraph and most (if not all) the Asset store shader creation tools support or add this by default.

Something to be aware of, just like any rendering technique the advantages are situational. Turning depth pre pass on could actually worsen performance depending one the scene,shaders,hardware,platform.ect.

If you want more technical information about "Depth Priming" aka "Depth Pre-pass" you can google it, there is a lot informative and well written articles on it.

 

One more question: what is the difference between Depth Priming and today's Depth Texture in URP that I can toggle already?

 

If you toggle on DepthTexture or if a ScriptableRendererPass request the depth texture then depth priming will automatically be used. The difference is now you have the option to force it, plus there is probably extra optimization from todays URP. I'm assuming that prior to the Depth Prime option that opaque objects might have still been sorted.

 

@NicoLeyman i am porting some shaders from urp 11 to 12 right now and unfortunately depth priming breaks my toon + outline shader which draws both in the same shader but in different passes.
so the outline just gets rejected because of depth testing.
i wonder if it is needed to use ZTest Equal in all cases?
needed for alpha testing to get rid of it but on a regular shader LEqual should do the job, right?
other than that: maybe we could exclude some shaders from using another ZTest than the original from the material using shader tags?

 

He mentions that Depth priming removes the need to sort opaque's, this might make it pretty difficult to get a toon outline shader using hull method to work properly because the depths could be written in random orders. I personally would make a custom ScriptableRenderer to render you're toon shaders, this would give you full control on how there rendered. You could removed the default universal shader tag from your shaders so they get skipped, then call your own Draw Renderers call from the scriptable context with your shader tag and specify the drawing order.

 

oh, i did not see this. but actually he wrote:

so they "try" - which i guess might be a bad idea as writing out the depth or depth normals would suffer from heavy overdraw then. less expensive than overdraw in the forward or gbuffer pass but still expensive.

 

"opaque" has been mentioned several times here and i admit i haven't looked into alpha tested geometry so far. but i really hope that depth priming will kill the clip command in the forward and deferred passes to enable early depth testing on these. just like in HDRP.

 

Oh I feel foolish! I did not realize that it was a whole separate thing, I thought he was referring to the existing depth pass used for the Depth texture.

 

Hi everyone, I'm trying to add depth priming on urp 7.x. But I 'm confused how do you solve the z fighting caused by depth prepass? Is there some offset for depth prepass so that lately the draw object pass can avoid the fighting artifacts?

 

i tried it once – copying the buffer generated for the shadows? well, i do not remember exactly.
turned out that the matrices were slightly off.

 

I'm interested in whether this feature changes anything for clipping on tile-based platforms (where alpha testing was usually discouraged). I noticed that enabling depth priming sets ZWrite to Off and ZTest to Equal on opaque draw calls. Has anyone had a chance to benchmark this yet? Can I go crazy with my alpha clipped vegetation?

https://forum.unity.com/threads/is-alpha-test-still-the-evil-for-mobile.507024/
https://forum.unity.com/threads/hlsl-is-there-any-point-to-clip-early.608692/
https://forum.unity.com/threads/general-questions-regarding-early-z.1065779/

 

Heya, thing is we have a game that uses A2C based shaders and MSAA for desktop but Depth Priming doesn't run if MSAA is enabled. There's no good technical reason for that as far as I've researched / asked around. Is this a legacy decision that will change?

As it means dropping our antialiased vegetation for a post effects based solution which changes the look of the game.

Further question for anyone: Is there a way to force the depth prepass version of the geometry to use a cheaper vertex shader for example we don't want wind in the prepass, as it adds up to being a waste of performance.

Shader uses shadergraph.

 

i haven't looked into URPs depth priming for quite a while... but speaking about HDRP and the depth prepass: using another vertex animation or even none would break the final render. the depth prepass writes out depth, then the regular shader drops alpha testing and uses ZTest Equal which gives you the same result and preserves early depth testing - but only if the final positions match.

 

I see, I figured that it wouldn't be noticed after a certain distance. So could drop vertex shader cost. I think it's probably better to disguise it and drop it earlier in the main pass then. One of those game rendering problems. Thanks!

 

you can fade it out and drop it beyond a certain distance – but you have to do so in both passes.

 

I mean, I'd avoid using it as it seems to be completely broken

https://i.gyazo.com/ff9e16fcff1afbeced4b3cbeb4587e3d.mp4

(and I have more important things wrong with Unity to try and debug, sadly, tho I wonder if it's related to being a long way from the origin)

 

I was mildly excited when I saw the depth priming feature in URP as I expected it would help me save a lot of performance on badly-sorted alpha-tested geometry (e.g. foliage) on mobile.
Unfortunately, it looks like all it does is worsen performance in general because it 1) renders depth to a texture, 2) copies the texture into the depth buffer of the main render. Is there no way to get around this? I was hoping such feature would rely on VK subpasses to avoid all the redundant data transfer.

 

The behaviour was changed in 2021.2 - what version are you using?

 

I'm using 2022.1 with URP 13.1.8.
I did just stumble upon an interesting comment in UniversalRendererRenderGraph.cs:

Code (csharp):

1. // Current aim of depth prepass is to generate a copy of depth buffer, it is NOT to prime depth buffer and reduce overdraw on non-mobile platforms

So I guess that's basically it for now :/

 

Are you still interested in reports of visual differences? And where should I report? I have a case where a mesh renders oddly when MSAA is turned on (URP). Its is like I can see through edges, but the mesh is fine - i double checked. By forcing depth priming I can get rid of that.

 

The two polygons are connected. This is what makes it so weird. But thanks for your input.

 

I wasn't able to make an object render behind everything else (regardless of its position) until I disabled depth priming. I suspect it ignores shader settings like disabling writing to the z buffer.

 

depth priming at least sets ZTest to Equal.

 

The fact that it does this silently sucks. Settings that become effectively disabled by some feature being enabled should be at least greyed out.

Or in the least having some clear documentation/tooltip describing this, which is also not the case for the depth priming checkbox.

 

i kind of agree. but actually depth priming has to override the ZTest – at least when it comes to alpha tested geometry. otherwise alpha tested would be as expensive as when not using depth priming (or better: even more expensive).
it does not have to override the ZTest of any opaque material. but it does.
ZTest LEqual should be fine with any opaque material and will not result in any overdraw or overshading.
When it comes to alph atested materials ZTest Equal replaces the clip() command which will make alpha tested materials render at full speed (including early z testing) when it comes to the gbuffers or forward passes.
a "trick" the addpass shader of the terrain might use as well - instead of doing alpha testing...

 

Couldn't the depth pre-pass just take into account depth testing settings in the material/shader? If the actual depth pass can, why wouldn't the pre-pass be able to?

It seems it just ignores it for no reason :/

 

it does afaik.
but then URP overrides ZTest for the "regular" passes like gbuffer or forward. would be nic eit would do so only on materials using alpha testing - just like HDRP does.

 

One of the tricks of Z Priming is to only use some of the bigger meshes that are closer to the camera and not the whole scene (from unity's own optimizations best practices). I don't know why there is no option to set a flag for objects in the scene that would suggest them specifically for this.