On Tue Apr 11 07:02:30 2023 +0000, Henri Verbeet wrote:
My understanding from the "Remarks" section in
https://learn.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-id3d12com... is this: suppose you create a command list that paints a resource all red and another one that paints the same texture all green. If you submit the two command lists with two separate `ExecuteCommandLists()` invokations, then you're sure the resource will be painted in whatever color is submitted last; Well, sure, but command buffers submitted to a Vulkan queue don't quite execute in random order either; submission order, primitive order, rasterisation order, etc. are all defined by the spec. Conor's comment seems to suggest this may be about ordering compute and graphics commands, which indeed normally don't wait for each other in Vulkan. Handling that wouldn't quite require a full memory barrier after each submission though. (Incidentally, we have barriers in adapter_vk_dispatch_compute() and wined3d_context_vk_end_current_render_pass() in wined3d for essentially this reason; there may be some room for optimisation there as well.) In any case, it would be nice if we were at least able to reproduce the issue this is trying to fix...
I think the issue is:
Unless otherwise specified, and without explicit synchronization, the various commands submitted to a queue via command buffers may execute in arbitrary order relative to each other, and/or concurrently. Also, the memory side effects of those commands may not be directly visible to other commands without explicit memory dependencies. This is true within a command buffer, and across command buffers submitted to a given queue.
The barrier is not needed if a semaphore is submitted after a command buffer. We could track that and only emit the barrier if necessary.
I've been unable to get the cacao demo to do anything. It just exits immediately.