I've trying to write a 3D engine using Metal. I want to understand how the order of encoding render/compute/blit commands affects the order of execution? Does the driver follow the order in which they're encoded by the app or does it try to optimize?
In other words, when one render pass generates data for the next render pass, is the order of encoding sufficient to ensure no RAW hazard on render targets?
The Metal Programming Guide states that:
All command buffers sent to a single queue are guaranteed to execute in the order in which the command buffers were enqueued.
Note that this does not say that commands complete before successive commands begin, nor does it say that writes from the first command will be visible to the next command. However, in my experience this is how metal behaves in practice. My guess is that the API detects resources dependencies conservatively, and fences commands within the command buffer so that GPU memory is guaranteed coherent between commands.
The documentation is clear though, that memory is CPU-GPU coherent only at boundaries between command buffers, but not between commands within a command buffer.