Page 1 of 1

store clause in quad pass of compositor script

Posted: Tue Jul 18, 2023 11:37 pm
by jwwalker

I'm trying to write a compositor node with a quad pass that reads color and depth, writes color, and leaves depth unchanged. But I'm unclear on what to write next to "depth" in the "store" clause.

Code: Select all

        pass render_quad
        {
            load
            {
                colour load
                depth load
            }
            store
            {
                colour store
                depth ?
            }
            material Foo
            input 0 depthTx
            input 1 colorTx
       }

As best I can tell, my options are dont_care, store, resolve, store_and_resolve, and store_or_resolve, but none of those seem to express what I want. I don't want to say dont_care, because I DO care what happens to the depth, I want to leave it alone. And all the other choices suggest doing something to the depth.


Re: store clause in quad pass of compositor script

Posted: Wed Jul 19, 2023 3:17 pm
by dark_sylinc

I understand your predicament but unfortunately dont_care also implies the contents of depth buffer after this pass are undefined.

RenderPassDepthTarget and RenderPassStencilTarget do have a flag called readOnly (see CompositorPassDef::mReadOnlyDepth & mReadOnlyStencil and boolean script flags depth_read_only and stencil_read_only) which seems to be what you're after. (Thinking out loud: perhaps it would be better if we change the boolean flag to a StoreAction instead, for consistency)

I don't know if the GPU actually optimizes performance based on this flag. Its main purpose is to tell the API and the GPU that you intend to bind the depth buffer both as a RenderTarget and for sampling as a texture at the same time in the same pass (this is only allowed as long as the depth/stencil buffer is bound as read only).


Re: store clause in quad pass of compositor script

Posted: Wed Jul 19, 2023 6:02 pm
by jwwalker

On further reflection, maybe it's not really a problem in this particular situation. I have a depth texture and a color texture as inputs, but if I don't link them together with an RTV and use only the color texture as a target, then I suppose there's no reason that my depth texture would be modified.