Does Metal strictly order execution of multiple command buffers hitting the same command queue?

[krackers]

Sorry for the maybe stupid question but I can't seem to find proper documentation on this anywhere, and unlike Vulkan, metal's precise semantics seem underspecified. So I'm hoping that the folks here who have experience with both could make a proper comparison:

Basically if you have 2 command buffers hitting the same command queue,

var a: MTLCommandBuffer
var b: MTLCommandBuffer
...
a.commit()
b.commit()

are you guaranteed that the first command in b is executed on the GPU after the last command in a completes execution on the GPU? Assume that Metal's Hazard tracking is disabled (because if it's enabled then I think that would prevent any observable violation anyhow).

I found this post https://forums.developer.apple.com/forums/thread/25270 which asks precisely the same question, and amusingly Bill left a comment back in 2015 that it was unclear to him. Almost a decade later and I still can't seem to find an authoritative answer anywhere.

https://stackoverflow.com/questions/55049995/ios-metal-command-buffer-execution-order and
https://stackoverflow.com/questions/38554896/how-does-the-gpu-driver-order-encoded-commands-in-mtlcommandbuffer?rq=3 likewise ask the same, but results are inconclusive.

[billhollings]

I think it's probably best to think of MTLCommandBuffer as just the mechanism of transmission between the CPU and GPU, and not as a context the GPU executes within. Effectively, it's a way of the CPU saying "here's a bunch of commands to run as an unbroken group", and optionally, "let me know when they are done", both of which are inter-processor communications.

But once the commands are enqueued on the GPU's internal queue, I don't think there is any meaningful delineation on the GPU between the last command in oneMTLCommandBuffer and the first command of the MTLCommandBuffer enqueued immediately after it. From the GPU's perspective, the commands might as well have been delivered to the GPU in the same MTLCommandBuffer (except for the optional CPU completion callback), and I expect that all the hazard-tracking, fence, and event behaviours apply identically.

IMHO...the confusion in all of those Q&A's (including mine) is in the inherent assumption that executes in order implies finishes in order. The GPU will certainly start executing commands in order, but the GPU is inherently massively parallel, and without some form of deliberate syncing or automatic hazard tracking, the assumption of finishing in order or finishing before staring the next, is incorrect.