commit c0ad0ea8b00fbdf5e13e6a8771ca05ec48230a22
author Lei Zhang <antiagainst@google.com> Sat May 06 18:02:02 2023 -0700
committer Lei Zhang <antiagainst@google.com> Tue Jun 13 21:17:32 2023 -0700
tree 1235d39be9b0cd6c862b6c329e3d61457383ba9c
parent ffb40b14e9ffd30ead8848a9c09b1b99ed313809

[metal] Switch to use command segments for recording command buffer

Unlike Vulkan, Metal adopts a multi-level command recording model--
memory/dispatch commands are not directly recorded into a command buffer;
rather, they must go through the additional level of blit/compute encoders.
IREE's HAL follows the flat Vulkan command buffer recording model, so we
have a mismatch here. Implementing IREE's HAL using Metal would require
switching encoders for interleaved memory and dispatch commands.
Additionally, certain IREE HAL API features do not have direct mapping in
Metal APIs, e.g., various forms of IREE HAL execution/memory barriers.
Translating them would require looking at both previous and next commands
to decide the proper mapping.

Due to these reasons, it's beneficial to have a complete view of the full
command buffer and extra flexibility during recording, in order to fixup
past commands, or inspect future commands.

Therefore, to implement IREE HAL command buffers using Metal, we perform
two steps using a linked list of command segments. First we create segments
(iree_hal_metal_command_buffer_prepare_* and iree_hal_metal_command_segment_create_*)
to keep track of all IREE HAL commands and the associated data, and then,
when finalizing the command buffer, we iterate through all the segments and
record their contents (iree_hal_metal_command_segment_record_*) into a
proper Metal command buffer . A linked list gives us the flexibility to
organize command sequence in low overhead; and a deferred recording gives
us the complete picture of the command buffer when really started recording.