Feature request (perf): generate command buffers that are VK_ONE_TIME_SUBMIT on the generation thread about moltenvk HOT 3 CLOSED

There are a few limitations that we’ll need to assess and resolve:

1. MTLCommandBuffers are disposable and can’t be reused…which means that population of the MTLCommandBuffer on the VkCommandBuffer population thread will only ever apply to the first submission to the queue. After that…each resubmission of the VkCommandBuffer would trigger the creation and population of a MTLCommandBuffer on the rendering thread.

2. MTLCommandBuffers must be created for a specific MTLQueue, whereas VkCommandBuffers are allocated via a command pool associated with a queue family. We could possibly map these together by limiting Vulkan to one queue per queue family…if such a limitation makes conceptual sense.

3. Creating one MTLCommandBuffer for each VkCommandBuffer works against the MTLCommandBuffer consolidation requested in issue #33 and implemented in PR #40. We could possibly provide a config switch that would let an app choose which optimization to use (consolidated MTLCommandBuffers vs sideband-thread population of a MTLCommandBuffer on the first submission of a VkCommandBuffer).

from moltenvk.

@billhollings Thank you for the analysis. Based on the excellent performance we are seeing from the work in #33 I am less convinced that what I proposed here is actually a good idea. For our engine, it will almost certainly make performance considerably worse based on what I've learned about how sensitive Metal is to command buffer granularity. I think doing this work should probably wait until there is an application that would benefit from it. It's OK with me if we close this bug for now.

from moltenvk.

This enhancement was added in PR #261. It defaults to disabled, and can be enabled via MoltenVK configuration.

from moltenvk.