Using CommandBuffers for early z-test rejection

Graphics Shaders & Materials
1

Hello! I’m trying to do, well, what the title says. I want to edit the depth buffer before rendering gets underway, as the camera I’m rendering with only has to render an extremely tiny amount of the screen. Culling off this extra area on the screen would save me like 90% rendertime per camera (which is very important in VR!) but no matter what I do I can’t seem to figure out how to get it to function.

cmdBuffer.Blit(BuiltinRenderTextureType.Depth, BuiltinRenderTextureType.Depth, depthClear);
            Camera.main.AddCommandBuffer(CameraEvent.BeforeDepthTexture, cmdBuffer);

That is the code that I’m using to attempt to clear the depth buffer of the camera to 0 after it is rendered, with this being the depthClear material shader:

Shader "Hidden/DepthBufferClear"
{
    Properties
    {
        _MainTex ("Texture", 2D) = "white" {}
    }
        SubShader{
        Tags{ "RenderType" = "Opaque" }
        ZTest Always Cull Off ZWrite On
        Pass{
        CGPROGRAM
#pragma vertex vert
#pragma fragment frag
#pragma target 2.0

#include "UnityCG.cginc"

        struct v2f {
        float4 pos : POSITION;
        float2 uv : TEXCOORD0;
    };

    struct fout {
        half4 color : SV_Target;
        float depth : SV_Depth;
    };

    uniform sampler2D _MainTex;

    v2f vert(appdata_base v) {
        v2f vo;
        vo.pos = mul(UNITY_MATRIX_MVP, v.vertex);
        vo.uv = v.texcoord.xy;
        vo.pos.z = 1;
        return vo;
    }

    fout frag(v2f i) {
        fout fo;
        fo.color = tex2D(_MainTex, i.uv);
        fo.color = (0, 0, 0);
        fo.depth = 1;
        return fo;
    }
    ENDCG
    }

    }
    FallBack "Diffuse"
}

Does anybody have any idea how this can be made to work? I wouldn’t think that setting the depth buffer would be this much of a pain… Hell, if I could even just set the camera to do a SIMPLE stencil test this would be much easier but Unity doesn’t let you reject fragments at rendertime unless you’re using a surface shader. Shouldn’t this shader be zeroing out the depth buffer?

2

The more I work on this, the worse it seems to get. No matter what is written to the depth buffer (in deferred OR forward), the camera continues on rendering. This is extremely disappointing, since I’m not sure what the depth buffer is even there for if writing to it doesn’t seem to cause any pixel rejection. Shouldn’t writing 1 to the entire depth buffer (before OR after the depthtexture is generated) cause it to reject every single fragment it tries to render?

3

Traditionally a depth of 1 is a cleared depth buffer, i.e. everything is as far from the camera as possible, try writing depth at 0.0?

Note in Unity 5.5 this is flipped for DX11 and a depth of 1 would be correct.

Also I’ve see some issues with drawing to depth with blit. You may need to do what you’re trying to do with a DrawMesh() instead.

You might also look into this: Unity - Scripting API: Camera.pixelRect

4

I’ve been able to successfully write to the depth buffer (1ing and zeroing it out) but neither of them actually resulted in fragments being rejected. Everything still is “rendered”, even if the screen is clearing to skybox.

5

Ah, I realized you’re rendering during the BeforeDepthTexture event, and the depth texture isn’t the zbuffer used during rendering. In forward that’s a separate texture renderered prior to the forward passes and set as a global texture, and in deferred it’s rendered after the deferred pass as a combination of the depth from the deferred and some additionally injected forward passes, though I don’t even know if that event gets fired during deferred.

What you want is to render during

Or

6

Unfortunately, no matter when I render the commandbuffer, even if it displays a pure white/skybox screen due to depth clearing, the performance does not increase at all and the graphics card is still rendering everything “behind” the rect.
Truly annoying, I wonder what on earth could be causing this. Every step in the frame debugger after the clear is just… nothing, or white, but it still takes up just as much rendering time.

7

Well, good news and bad news. Good news is that I found out where openVR does it, but I have absolutely no idea how it’s submitting the draw call

Does anybody know how I could insert a draw call directly after clear? It seems that calling the commandbuffer doesn’t trigger the early-z rejection.

8

That’s not something specific to openVR, that’s just where Unity does its clear of the depth texture. And again the depth texture has nothing to do with the zbuffer used when rendering the forward or deferred passes, it’s completely separate or at best a copy of the depth buffer after the fact. Also if you’re expecting to see things disappear from the frame debugger, that’s just showing the CPU side calls. Unity’s culling doesn’t use gpu occlusion so they’ll still show up in the frame debugger even if the first thing that renders covers the entire view.

The only way to see if your pixels are actually getting rejected is if the GPU time decreases, or using RenderDoc to see what’s happening on the GPU. If you’re not fillrate bound, it’s unlikely what you’re doing will actually noticeably increase framerate.

9

My images are unfortunately inaccurate- they were from before I realized that the depth texture wasn’t what I was looking to modify (I was confused by the fact that OVR drew its stencil during it), but even though I’ve since moved my depth drawing to beforeforwardopaque, it is not actually rejecting the fragments.
Also, you say that the results won’t show up in the frame debugger, but that isn’t true- the mask from OVR flat-out rejects fragments all the way through the entire frame debug, and the mask is visible for the entire render.
I’m a little confused as to why you say that this wouldn’t increase performance. How would rendering 1/10th of a camera not be significantly faster?
Breakdown:

If I’m barking up the wrong tree, then what should I be doing instead? Unity must support some way to do away with parts of the frame that won’t be rendered (like a scissor test) for performance reasons.

10

Those are still showing you drawing during the depth texture creation, which is producing correct results in blanking out the depth texture, but will have no effect on the final render (apart from possibly messing with shadows or other effects that rely on the depth texture).

Just ignore everything under the UpdateDepthTexture right now, and move your depth pass to run during CameraEvent.BeforeForwardOpaque. If you look for Camera.Render > Drawing > Render.OpaqueGeometry > RenderForwardOpaque.Render > RenderForward.RenderLoopJob there’s another clear just before that which is probably another Draw GL like what you’re seeing prior to the UpdateDepthTexture > DepthPass.Job. If you use CameraEvent.BeforeForwardOpaque you should get a CommandBuffer.BeforeForwardOpaque event right after that to blank out the zbuffer with.

11

Right, that’s what I’m doing (I mentioned that the picture wasn’t my current method in that post, but I don’t blame you for not seeing it). I am drawing to the depth buffer before the forward opaque, but it is still not actually rejecting the fragments. With the depth buffer having a solid 1 written to it to trigger the near clip early rejection, It renders a pure black screen- however, my GPU performance doesn’t actually increase whatsoever (In any sense- framerates remain constant, GPU load doesn’t drop, nothing). RenderDoc reports the same as the frame debugger- the depth buffer gets written to a solid 1, and then it renders everything else as per normal at the exact same speed as it does when rendering normally.

12

Ah.

Yep, missed that.

I took a couple of minutes to setup a test case. A stupid expensive shader, a shader that writes depth, and a script to blit that to the camera. Worked fine for me.

Here’s the shaders and code I used.
Code

Shader "Unlit/StupidExpensive"
{
    Properties
    {
        _MainTex ("Texture", 2D) = "white" {}
    }
    SubShader
    {
        Tags { "RenderType"="Opaque" }
        LOD 100
        Cull Off

        Pass
        {
            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag
        
            #include "UnityCG.cginc"

            struct appdata
            {
                float4 vertex : POSITION;
                float2 uv : TEXCOORD0;
            };

            struct v2f
            {
                float2 uv : TEXCOORD0;
                float4 vertex : SV_POSITION;
            };

            sampler2D _MainTex;
            float4 _MainTex_ST;
        
            v2f vert (appdata v)
            {
                v2f o;
                o.vertex = UnityObjectToClipPos(v.vertex);
                o.uv = TRANSFORM_TEX(v.uv, _MainTex);
                return o;
            }
        
            fixed4 frag (v2f i) : SV_Target
            {
                // sample the texture
                float4 col = 0;
                float2 uv = i.uv;
                float s = 0;
                for (int iter=0; iter<10000; iter++)
                {
                    s += 0.151;
                    uv += sin(s);
                    col += tex2D(_MainTex, uv);
                }

                col /= 10000;
                return col;
            }
            ENDCG
        }
    }
}

Shader "Unlit/WriteToDepth"
{
    Properties
    {
        _Depth ("Depth", Range(0,1)) = 0
    }
    SubShader
    {
        Tags { "Queue"="Background" } // irrelevant for blit, but useful for testing
        LOD 100

        Pass
        {
            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag
        
            #include "UnityCG.cginc"

            struct appdata
            {
                float4 vertex : POSITION;
            };

            struct v2f
            {
                float4 vertex : SV_POSITION;
            };
        
            v2f vert (appdata v)
            {
                v2f o;
                o.vertex = UnityObjectToClipPos(v.vertex);
                return o;
            }

            float _Depth;
        
            fixed4 frag (v2f i, out float out_depth : SV_Depth) : SV_Target
            {
                out_depth = _Depth;
                return 0;
            }
            ENDCG
        }
    }
}

using UnityEngine;
using UnityEngine.Rendering;
using System.Collections;

[RequireComponent(typeof(Camera))]
public class DebugDepthWrite : MonoBehaviour {

    public Material depthMat;
    private CommandBuffer cmdBuffer;

    void OnEnable() {

        Camera cam = GetComponent<Camera>();

        cmdBuffer = new CommandBuffer();
        cmdBuffer.name = "Depth Write";

        cmdBuffer.Blit(BuiltinRenderTextureType.CurrentActive, BuiltinRenderTextureType.CurrentActive, depthMat);

        cam.AddCommandBuffer(CameraEvent.BeforeForwardOpaque, cmdBuffer);
    }

    void OnDisable() {
        Camera cam = GetComponent<Camera>();

        cam.RemoveCommandBuffer(CameraEvent.BeforeForwardOpaque, cmdBuffer);
        cmdBuffer = null;
    }
}

I put the “StupidExpensive” shader on a sphere, pointed a camera at it, added the component to the camera and assigned a material with the depth write shader to the component. Toggle it on and off I saw the FPS go from <20 to >2000.

The depth write shader defaults to writing to zero since I’m using an older version of Unity atm, but if you set it to 1 on the material or use your own shader it should work just as well.

2 Likes
13

Thanks for the writeup, it works perfectly! It turns out that I, in my infinite wisdom, had a second point light sun from an older revision of my code sitting beneath the terrain which was casting dynamic shadows. This was resulting in my depth buffer writing not really mattering that much when it came to the final rendering cost, since shadows are rendered whether or not they are occluded… I feel like a pretty big chump right now.
Thanks!

I guess I’m off to try and figure out how OVR shares shadow maps between eyes so I can use that on my portals as well.