[16/n] ResourceTracker: add mechanisms to record pending commands
Bug: 177241396
This is most of the heavy logic around VulkanQueueSubmitWithCommands.
First, we provide new methods to ResourceTracker to acquire encoders
specific to VkCommandBuffers and VkQueues. We don't use the
VkQueue-specific encoder any differently from before though.
Next if the feature is enabled, we use an encoder specific to the
command buffer when recording command buffer dispatched Vulkan API
calls. Each command buffer uses a CommandBufferStagingStream to store
intermediate streaming data for the host.
However, this scheme means that it's possible to include stale command
buffer data that the host shouldn't decode, such as when we record a
bunch of commands and then before submitting, reset the command buffer.
Indeed, the Vulkan spec has rules around when a command buffer's
currently-recorded results must be ignored:
- On command buffer reset (e.g., any vkBeginCommandBuffer,
vkResetCommandBuffer, vkResetCommandPool, and any operation that deletes
a command buffer or its command pool).
- When a command buffer's secondary command buffer is reset.
So we maintain (using the new linked-list mechanisms) a list of
VkCommandBuffers, primary and secondary, and recursively (well, there is
only one level of recursion allowed (so far)) reset command
buffers/pools depending on the action. We also need to instrument
vkCmdExecuteCommands to link primary and secondary command buffers,
and add routines that run when command buffers/pools are
reset/destroyed.
This also requires accompanying codegen; it's not hooked up to anything yet.
Change-Id: If1927b2e9bf1d63ccc4529909aa5c8d3180ef476
3 files changed
