Proposal for new command buffer types

[Rua]

At the moment, when you use AutoCommandBufferBuilder, it performs both validation of the command and automatic insertion of pipeline barriers. But it's quite possible that a user might want to do their own barriers manually. There may be situations where they can't be done automatically, or where the automatic method is inefficient.

Currently, the user's only option is to use UnsafeCommandBufferBuilder. But this type is very unsafe; by using it, the user loses out on the command validation and also loses the ability to automatically keep resources alive inside the command buffer. It would be useful to have access to the safety of AutoCommandBufferBuilder without automatic barrier insertion.

So my thought is to rearrange the current types into two new layers: a safety/validation layer and an automatic barrier insertion layer.

• The builder types UnsafeCommandBufferBuilder and SyncCommandBufferBuilder would go.
• There would only be two types for built command buffers, PrimaryCommandBuffer and SecondaryCommandBuffer. The corresponding traits would go.
• A new type CommandBufferBuilder representing the safety/validation layer. It would validate all commands and keep resources alive, like AutoCommandBufferBuilder does now. It would not insert any barriers automatically, instead having a pipeline_barrier command to manually insert a barrier. But crucially, this command would be safe and every call would be validated just like other command buffer commands. CommandBufferBuilder would keep track of accesses and validate the barriers inserted by the user to ensure they got it right.
• AutoCommandBufferBuilder would do what it does now, but it would be implemented on top of CommandBufferBuilder, by adding the automatic barrier insertion. Because the CommandBufferBuilder still validates the barriers, any bugs in AutoCommandBufferBuilder would hopefully be caught by the lower layer. In principle, AutoCommandBufferBuilder would just be one possible auto-barrier layer, the user could build their own if they wanted to.

[ProbabilisticS]

I like the idea of a command buffer builder with explicit memory barrier setup functionality. Is this proposal in development, and if so, is there an estimate of when it would be implemented?

[marc0246]

I could work on this, but I can't give you any estimate as there's other issues that have priority for me. Nonetheless I think this will be a good improvement and would like to see it implemented.

[marc0246]

What is also important to mention I think is that neither UnsafeCommandBufferBuilder nor SyncCommandBufferBuilder keep alive the command pool allocation. So it is very inconvenient to try and implement a manual command buffer. In my opinion, the management of resources (including keeping the command pool alloc alive) is the one thing that we want from the lowest level, because any lover than that and you might as well use ash::vk::CommandBuffer.

[Rua]

I've already started working on this.