wgpu_hal::vulkan::Queue::relay_semaphores may be unnecessary

[jimblandy]

In the wgpu_hal Vulkan backend, it may be unnecessary to use Queue::relay_semaphores to establish the execution ordering between successive queue submissions that is promised by wgpu_hal::Queue::submit. If the buffer and texture pipeline barriers are generated correctly, then that should be all we need.

Vulkan defines submission order as follows:

Submission order for any given set of commands is based on the order in which they were recorded to command buffers and then submitted. This order is determined as follows:

1. The initial order is determined by the order in which vkQueueSubmit and vkQueueSubmit2 commands are executed on the host, for a single queue, from first to last.

2. The order in which VkSubmitInfo structures are specified in the pSubmits parameter of vkQueueSubmit, or in which VkSubmitInfo2 structures are specified in the pSubmits parameter of vkQueueSubmit2, from lowest index to highest.

3. The order in which command buffers are specified in the pCommandBuffers member of VkSubmitInfo or VkSubmitInfo2 from lowest index to highest.

4. The order in which commands outside of a render pass were recorded to a command buffer on the host, from first to last.

5. The order in which commands inside a single subpass were recorded to a command buffer on the host, from first to last.

Note that submission order is not execution order: there is no guarantee that, just because A precedes B in submission order, that A will finish execution before B begins, or that A will even begin execution before B does. What you need is an execution dependency between A and B.

It turns out that vkCmdPipelineBarrier, which we already emit between any two operations that need it, defines memory dependencies

between commands that were submitted to the same queue before it, and those submitted to the same queue after it.

I'm not familiar with this part of WebGPU or this part of Vulkan, so, definitely check my work. But we already emit wgpu_hal barriers between:

• any two operations that write,
• any operation that reads and any operation that writes, and
• any operation that writes and any operation that reads

Depending on the details of the Vulkan pipeline barrier that records, that should establish dependencies sufficient to fulfill the promises wgpu_hal::Queue::submit makes.

If that's so, we could just delete wgpu_hal::vulkan::Queue::relay_semaphores altogether.