tree 286fb1f55a4089ed718915ef0bc7c1a7f5861569
parent 3cfb1a24e22e93a771d6ffc0c8f039d874a09281
author Lingfeng Yang <lfy@google.com> 1560803242 -0700
committer Lingfeng Yang <lfy@google.com> 1561405968 -0700

[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