[19/n] VkDecoderGlobalState: VulkanQueueSubmitWithCommands
Bug: 177241396
This contains the bulk of the protocol changes for the
VulkanQueueSubmitWithCommands optimization. It has two aspects,
both of which are guarded by a feature flag:
1. Adding a sequence number to each encode/decode
2. Not serializing the dispatch VkCommandBuffer if we are doing queue
submit along with commands, since we already know which VkCommandBuffer
to use.
The global sequence number has the effect of imposing a strict global
sequence on all calls, which makes us slower than before in a lot of
cases (esp ones where there is lots of multithreaded activity), but
overall increases correctness.
However, we do relax the global sequencing in some cases, such as for
the vkWait* operations and vkQueueFlushCommandsGOOGLE. RELAXED commands
cannot be reordered before any non-relaxed commands that have a lower
client sequence number, but can be reordered both before and after other
RELAX commands, and reordered after commands with a higher sequence
number. That is, our current situation is that vkCmd* are arbitrarily
reordered (to support command recording parallelism) but most non-vkCmd*
API calls get the global ordering treatment.
The next step would be to introduce some notion of per-object sequence
number and have the guest tag each object with a notion of acquire and
release operation, not like atomic APIs. This will let us more freely
retire API calls in different orderings without affecting semantics, nor
having to construct and consume a command dependency graph.
Also:
Decoding command buffer intermediate contents from the guest
(subdecoding) is now connected to VkDecoderGlobalState.
When we subdecode we spawn a reading stream (from a pool of them
so we don't reallocate every time), and pass that to the subdecode
routine (which is codegenned)
Change-Id: Ide39da51d35ca151e2ad5a8b58829aa9d1ebc027
7 files changed
tree: 3b0159cb7ab86b89d5b0ab644cab3b3354b7ffe0
- registry/