Hi Forum!

I am in half way of redesigning abstraction representations of 2D textures in my engine (CPU side) for:
RenderTarget, DepthStencil, and array versions of them.

And I would like to clarify some design decisions before starting to code.

============================================

RenderTarget2D abstraction

Consider this interface for render target 2D (not array version):

class RenderTarget2D
{
    ComPtr<ID3D11Texture2D>           m_texture;
    ComPtr<ID3D11RenderTargetView>    m_rtv;
    ComPtr<ID3D11ShaderResourceView>  m_srv;
    ComPtr<ID3D11UnorderedAccessView> m_uav;
}

Questions1:
If I create UAV for any RenderTarget2D, can it degrade performance in runtime?
Can hardware treat texture with UAV as slower version than a texture, created without UAV?

============================================

DepthStencil abstraction
I haven’t found a good way of using Stencil part of it.
For deferred rendering and shadow generation I don’t use Stencil.

Question2:
Are there use cases in modern rendering when Stencil is useful?

============================================

DepthTexture2D abstraction

Question3:
Is it right way to say, that Depth texture without “Stencil” part can be treated as regular texture2D with next statements:
1. Format of Depth should start with D, but RenderTargets – from R?
2. CreateDepthStencilView() should be substituted with CreateRenderTargetView()
Are there other fundamental differences between them?

============================================

DepthArray2D abstraction (without stencil part)
In Shadow map generation, I need DepthStencilArray with 4 slices without stencil part.

class DepthArray2D
{
    ComPtr<ID3D11Texture2D> m_texture;

    ComPtr<ID3D11ShaderResourceView>              m_srv;       // As Texture2DArray in hlsl
    std::vector<ComPtr<ID3D11ShaderResourceView>> m_srvSlices; // As Texture2D  in hlsl

    ComPtr<ID3D11DepthStencilView>              m_dsv;
    ComPtr<ID3D11DepthStencilView>              m_dsvRO;
    std::vector<ComPtr<ID3D11DepthStencilView>> m_dsvSlices;
}

Question4:
Is it right thing to say that DepthStencilArray is the same as Texture2DArray (I can create SRV slices as in Texture)?

Thanks in advance!

Thank you Hodgman for your answer!

Question2: Are there use cases in modern rendering when Stencil is useful?

2) yes... But if you don't need them right now, then just stub out enough of the API so that you can implement stencil support later, and then implement stencil support later! :)

That's the plan: remove all stencil-related code from current implementation and call the abstraction "DepthTexture"! :)

If one day I will need a stencil in it, I would probably create a new additional class "DepthStencilTexture".

But for now I would like to know, are there use cases at all in modern engines?

Do you use it?

Could you provide use cases, when it really needed?

3.2) i don't understand what you're asking. You don't create an RTV for a depth-only depth-texture.

I have next assumption: DepthTexture is the same as regular RenderTarget, but:

1. Can be bound as depth texture in the pipeline (3rd param instead of 2nd for regular RT:

m_context->OMSetRenderTargets(1, &rtv0, pDepthStencilView);

2. "RTV" for depth texture is called "DSV", so different function calls to create it from Device, but the functionality is the same: it is a target to write to.

3. SRV in both cases have the same functionality.

4. There is notion of "Read-only DSV".

And the question probably should be stated: are DepthTexture and RenderTexture more different than that (let's put aside "Stencil" part here)?

Off topic but what you shown is not an abstraction, it is object members. An abstraction is about member functions and services, not implementation.

I showed only part of implementation: COM members.

The abstractions also include:

0. Construction

1. Resize()

2. Uniform SetPrivateData() for texture/SRV/RTV/UAV.

3. Holding texture formats/other types.

4. Lifetime management.

5. Accessors.

But all the things above were clear to me.

Some use cases were blurry.

Thanks to Hodgman, now I have all I need for redesign. :)