[vulkan] Maintain order of begin/end command buffer in deferred mode
bug: 135464985
If we record command buffers in async mode (no return from
vkBegin/EndCommandBuffer) in several guest threads,
it's possible the commands end up out of order when they arrive on the
host, leading to cool bugs.
To ensure the order when async mode is active, we use a special command
vkCommandBufferHostSyncGOOGLE
when the guest thread used to record to a command buffer switches.
Two issues of vkCommandBufferHostSyncGOOGLE are done:
1. The previous encoder issues vkCommandBufferHostSyncGOOGLE with the
previous sequence number.
2. The current encoder issues vkCommandBufferHostSyncGOOGLE with the
incremented sequence number along with a flag to wait on the host for
the vkCommandBufferHostSyncGOOGLE with the previous sequence number.
3. If the previous encoder is destroyed, we register a cleanup callback
that updates the pointer accordingly, so that we dont perform a stale
access.
By introducing this new command, we can then record command buffers
completely async and avoid having to add sequence numbers
to every command buffer recording API.
Note: We previously explored a solution where all command buffer
recording to be in one pipe, to implicitly accomplish ordering of
command buffer APIs. However, that turned out to be extremely difficult
to synchronize with other Vulkan APIs that were not concerned with
command buffer recording, as they could and sometimes need to run in
their separate threads.
Change-Id: I093be0a1600f22e0a355536d1671acdce3852541
9 files changed
