I’m currently struggling with an issue and couldn’t find if there’s a workaround for it on Vulkan.
I have some pre-recorded secondary command buffers that are used for all the static draw commands in our game and the viewport/scissor are dynamic - so they have to be updated for each command buffer.
Now the problem is that since the game also uses dynamic resolution, the viewport/scissor recorded on those secondary command buffers might not match the one currently used on the current frame.
It would be great if the restrictions (setting the dynamic states) applied only to the primary command buffer instead, since secondary CBs can’t be executed directly anyway.
We could then do something like (and for the record that’s basically what we do on DX12):
allocate secondary command buffer
begin secondary command buffer
set scissor
set viewport
end secondary command buffer
if (updateStaticCommandBuffer)
{
begin secondary command buffer
draw
end secondary command buffer
}
execute commands (pass both secondary command buffers)
But currently the dynamic states need to be set on every command buffer, forcing us to recreate the static CBs every time the resolution changes.
Vulkan secondary command buffers are not like Direct3D 12’s “bundles”. Vulkan secondary command buffers are almost entirely isolated from the state of the context in which they are used. This is by design.
Vulkan has no equivalent to bundles, so you have to meet Vulkan where it is and how it is working. So rebuild the command buffers.
Thank you for the clarification.
Is there no other way around this? It would really be a shame if we absolutely need to rebuild those command buffers if only dynamic state changes.
My current (and probably not very accurate) measurements show that we save around 3ms CPU time when those command buffers aren’t recreated. Having to do this every time dynamic resolution scales the viewport means that we basically have a tradeoff between GPU and CPU time, defeating the purpose of the technique (and possibly introducing stuttering)
Maybe you can work on fixing that problem. I don’t know what’s going on in these static command buffers, but perhaps there are more efficient ways to build these CBs once you remove the need for them to be static. Or maybe just employ another thread to do the job.