Gfx: color-uniform example drops in framerate over time

[rishflab]

Short info header:

• GFX version: hal-0.2 (branch)
• OS: Windows 10 x64
• GPU: AMD RX580 4GB
• Backends: Vulkan

How to reproduce:

cd gfx/examples
cargo run --bin colour-uniform --features vulkan

(i have made this branch with frame time print out if you are feeling lazy https://github.com/rishflab/gfx/tree/issue-2818)

The framerate drops gradually over time when running the color-uniform example. It starts at around 150fps and after about 3 minutes it is at around 50fps.

This only happens with the vulkan backend. The dx12 backend maintains a steady 150fps.

My guess it is due to the way the synchronisation is setup in the example. I have used the synchronisation setup from this example in my own project and I am having the same issue. I profiled it the radeon profiler and what I found was that there was a period of time with 0% gpu utilisation which was gradually increasing.

The quad example uses a different synchronisation setup and does not suffer from this issue.

Tested on 2014 Macbook pro:
I tried the example on a 2014 macbook pro (Mac OSX, metal, nvidia gt750m) and it works fine.

[kvark]

That's kinda interesting - the Vulkan backend is supposed to be fastest. Maybe we are accumulating some heap-allocated storage (for temporary data) that never gets shrunk?

[rishflab]

In the colour-uniform example, command buffer creation occurs in a loop

loop {
   let mut cmd_buffer = command_pool.acquire_command_buffer::<command::OneShot>();
}

In the quad example, a multishot command buffer is pre-allocated for each in flight image outside of the main loop

Could the acquire_command_buffer call be allocating memory on the gpu, which is not being freed?
command_pool.reset() should free all of the command buffers?

[kvark]

The command pool is owned by a frame and gets reset at the start of the frame, so resources should be freed by that.

[ghost]

Looking at the implementation of the reset method for the command pool, I don't believe we're passing in the VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_FLAG that would release the memory held by the command buffers.

[kvark]

Oh snap, so we are blocked by #2407

[msiglreith]

The example seems to creating new command buffers every frame but never free them again. I'm feeling that this has a larger impact.

I'm noticing any fps drops as well with nvidia drivers