Idling or flushing context before graphical resources are released?

[RobertMtx]

What is the correct way to handle Diligent Engine right before releasing graphical resources that may still be in use by the GPU? I've sometimes noticed weird flickering when exiting menus or shutting down the app. I believe this is caused by the resource being lost before the command is executed on the GPU.

I'm assuming this concept is pretty universal, regardless of how the engine is used, but please let me know if any specifics are important.

I'm currently using Diligent::IDeviceContext::Flush(), then Diligent::IRenderDevice::IdleGPU() right before graphical resources like textures and GPU buffers are released. Is this correct? And is there anything else I should be aware of?

My application avoids doing any of this in the middle of a drawing routine, so this process only happens outside of the rendering section. Intentionally.

I'm also aware of fences, but have largely avoided getting familiar with them. I believe I am using some type of barrier when switching certain resource states, such as switching the shadowmap between render target and shader resource. But apart from this, I haven't done much with any type of barriers or fences. I definitely intend to learn more about them, though.

Appreciate any advice!

[TheMostDiligent]

Normally, you don't need to do anything - Diligent handles resource lifetimes and don't release them if they are in use by the GPU.

I'm currently using Diligent::IDeviceContext::Flush(), then Diligent::IRenderDevice::IdleGPU() right before graphical resources like textures and GPU buffers are released.
My application avoids doing any of this in the middle of a drawing routine, so this process only happens outside of the rendering section.

Like I said, this is not necessary. Flush() is called automatically by SwapChain::Present. Also, if you call IdleGPU each frame, or even periodically, this creates a bubble and reduces performance whether it is inside the render loop or not. IdleGPU should typically never be called when the app is running.

I'm also aware of fences, but have largely avoided getting familiar with them

Again, you don't normally to do anything - resource lifetime tracking is handled automatically.

There may be multiple other reasons for flickering. Do you see anything in the output? If you use Vulkan, validation layers should definitely complain if resource are being used after being destroyed.

[RobertMtx]

I'm using DirectX12. I'm definitely seeing changes when I flush+idle versus not. But after working with it more yesterday, I've found that it seems to primarily be related to my texture assignments, rather than resources being released. I use a texture array in the shader, and assign/unassign individual slots of the array at runtime. When a texture is released, or I run out of slots, I have to clear texture assignments in that texture array. It seems most of my flickering is caused by this clearing of the texture, rather than releasing anything.

Would you recommend a different method for this action? Maybe using some type of fence here? Or is flush/idle the way to go? Let me know if you need any specifics.

I also encountered this (random) exception while exiting my app, just a few minutes ago. This may be unrelated, but let me know if you are able to quickly discern what's happening here. The exception was triggered by accessing a null pointer. It seems to be related to a resource barrier, but I'm not sure what happened. This does not happen often.

Thanks, I appreciate the advice.

[RobertMtx]

The exception seems to be because I was calling flush/idle right before release. So yeah, if there is a better way to have the CPU wait for drawing to finish before I change texture assignments, that information would be much appreciated. Thanks.

[TheMostDiligent]

I use a texture array in the shader, and assign/unassign individual slots of the array at runtime.

You mean you have an array like Texture2D g_Textures[128] and you assign slots in it dynamically?
How do you set new textures? Do you use the SET_SHADER_RESOURCE_FLAG_ALLOW_OVERWRITE flag?

[RobertMtx]

Yes, that's exactly right - but with Textures[256]. ShaderArrayVariable->SetArray( ShaderObjectsPtr + texture_slot, texture_slot, 1, Diligent::SET_SHADER_RESOURCE_FLAG_ALLOW_OVERWRITE );
After reading the comments around Diligent::SET_SHADER_RESOURCE_FLAG_ALLOW_OVERWRITE, it sounds like I probably do want to use some type of fence for this?

My app does not change textures very often. Especially not textures being drawn. Only in situations where objects are dying, areas are transitioning, etc. In most other cases, the object would just register multiple textures and use both. But if there is a correct way to handle this, I would prefer to go that route.

[TheMostDiligent]

The very reason why the engine does not allow overwriting the resources by default is because it is a synchronization hazard. The purpose of the SET_SHADER_RESOURCE_FLAG_ALLOW_OVERWRITE flag is to make it explicit and draw attention that it is disallowed by default.

it sounds like I probably do want to use some type of fence for this?

    ///         When overwriting a mutable variable binding in Direct3D12 and Vulkan,
    ///         an application must ensure that the GPU is not accessing the SRB.
    ///         This can be achieved using synchronization tools such as fences.
    ///         Synchronization with GPU is not required in OpenGL, Direct3D11,
    ///         and Metal backends.

An application must ensure synchronization.

You need to track the GPU execution with fences. When a texture is not used anymore, you keep track of the frame number when it was used last time. You can only reuse the slot when the fence indicates that the frame is complete and the texture is not used by the GPU anymore.