Wrapping device objects & refcounters behavior question

[dolphineye74]

Hi there,

I was playing a bit with Diligent recently, and I came across the need to create device object proxies to have some kind of create/destroy listener pattern in my app.

Goal

The gist of my original idea was something along what I did for my material system:

auto Engine::CreateMaterial(...)
{
    auto material = std::shared_ptr<Material>(new Material(...), [this](auto *ptr)
    {
        for (auto* listener : listeners)
        {
            listener->OnDestroy(*material);
        }
        delete ptr;
    });
    return material;
}

First approach

My original idea was as simple as follows, similar to what was done with the reloadable pipeline proxy:

class TextureProxy : public Diligent::ObjectBase<Diligent::ITexture>
{
    using Base = Diligent::ObjectBase<Diligent::ITexture>;

    using DestroyListenerFunction = std::function<void(Diligent::ITexture&)>;

public:
    TextureProxy(Diligent::IReferenceCounters*                inRefCounters,
                 Diligent::RefCntAutoPtr<Diligent::ITexture>  inOriginalTexture, // <-- Shared pointer on the original
                 DestroyListenerFunction                      inDestroyListenerFunction)
        : Base(inRefCounters)
        , originalTexture(inOriginalTexture)
        , destroyListenerFunction(destroyListenerFunction)
    {
    }

    virtual ~TextureProxy()
    {
        if (destroyListenerFunction)
        {
            destroyListenerFunction(*originalTexture);
        }
    }
};

auto Engine::CreateTexture(...)
{
    // Create the original texture
    Diligent::RefCntAutoPtr<Diligent::ITexture> originalTexture;
    renderDevice->CreateTexture(textureDesc, initialData, &originalTexture);

    // Create the texture proxy
    const auto destroyListenerFunction = [this](Diligent::ITexture& texture) {
        for (auto* listener : listeners)
        {
            listener->OnDestroy(texture);
        }
    };
    Diligent::RefCntAutoPtr<TextureProxy> textureProxy{
        Diligent::MakeNewRCObj<TextureProxy>()(texture, destroyListenerFunction)
    };
    return textureProxy;
}

Pseudo-code usage example of how I use my textures with my material system:

Diligent::RefCntAutoPtr<Diligent::ITextureView> LoadTextureFromFile(Engine& engine, const String& filePath)
{
    // Parse the texture data
    // ...

    // Create the texture (which returns the proxy)
    Diligent::RefCntAutoPtr<Diligent::ITexture> texture = engine.CreateTexture(...);

    // Return the texture's default SRV view
    return texture->GetDefaultView(Diligent::TEXTURE_VIEW_SHADER_RESOURCE);
}

// Usage example
auto albedoTextureView = LoadTextureFromFile(engine, ...);
auto materialInstance = engine.CreateMaterialInstance(*material);
materialInstance->SetTexture("albedo_texture", albedoTextureView);

The problem I am facing is that the original texture creates default views that will increments the texture's ref count.

My proxy does not benefit from this ref count increment, so once I pass the texture view to my material, the original proxy texture is destroyed.

Second approach

I tried with another approach via the IObject* pOwner parameter of MakeNewRCObj to share the reference counters of my original texture with my proxy:

class TextureProxy : public Diligent::ObjectBase<Diligent::ITexture>
{
    using Base = Diligent::ObjectBase<Diligent::ITexture>;

    using DestroyListenerFunction = std::function<void(Diligent::ITexture&)>;

public:
    TextureProxy(Diligent::IReferenceCounters* inRefCounters,
                 Diligent::ITexture&           inOriginalTexture, // <-- Plain reference to the original
                 DestroyListenerFunction       inDestroyListenerFunction)
        : Base(inRefCounters)
        , originalTexture(inOriginalTexture)
        , destroyListenerFunction(destroyListenerFunction)
    {
    }

    virtual ~TextureProxy()
    {
        if (destroyListenerFunction)
        {
            destroyListenerFunction(originalTexture);
        }
    }
};

auto Engine::CreateTexture(...)
{
    // Create the original texture
    Diligent::RefCntAutoPtr<Diligent::ITexture> originalTexture;
    renderDevice->CreateTexture(textureDesc, initialData, &originalTexture);

    // Create the texture proxy
    const auto destroyListenerFunction = [this](Diligent::ITexture& texture) {
        for (auto* listener : listeners)
        {
            listener->OnDestroy(texture);
        }
    };
    Diligent::RefCntAutoPtr<TextureProxy> textureProxy{
        Diligent::MakeNewRCObj<TextureProxy>(texture /* pOwner */)(*texture, destroyListenerFunction)
    };
    return textureProxy;
}

Now my proxy's destructor is never called :/

Based on what I could read, it seems that specifying a pOwner just prevents the creation of a new reference counter object.

The underlying object's memory is properly allocated, but it is never freed as the shared ref counters will only destroy the original object it owns (i.e: my original texture).

Conclusion

I haven't found any reliable way to properly wrap a device object and it appears the pOwner parameters of MakeNewRCObj can lead to memory leak situations if used.

Questions :

1. Is there any reason behind pOwner in the first place?

2. Any good tips to figure out when a device object is destroyed?

[TheMostDiligent]

1. Is there any reason behind pOwner in the first place?

It is intended to handle cases when one ref-counted object is part of another, like default texture view. In this case, default texture views use ref counting object from the parent object instead of creating its own. As a result, you can do

pDevice->CreateTexture(&pTexture);
pView = pTexture->GetDefaultView();
pTexture.Release();

And pView will keep the texture object alive while internally it is part of the parent texture object.

2. Any good tips to figure out when a device object is destroyed?

The API does not give this option. For internal use, there is this version of Release.

Why do you need this BTW?

[dolphineye74]

Why do you need this BTW?

Thank I will have a look.

I needed to notify of some texture destructions using the listener pattern.

I ended up doing it differently via a wrapper std::shared_ptr.

I might very well change this to a polling system to detect stale RefCntWeakPtr.

I was just being curious about the pOwner topic.