Metal 4 Synchronization

Overview

Metal 4 requires fully explicit synchronization — there is no driver hazard tracking. All resource dependencies between encoders and passes must be expressed through barriers, fences, or events. This is typically the longest phase of a port — expect barrier and synchronization work to account for a significant portion of total porting effort.

The key insight: all source API synchronization models reduce to Metal 4 primitives — producer barriers (on outgoing encoder), consumer barriers (on incoming encoder), intra-pass barriers (within an encoder), fences (between specific encoders on the same queue), and events (cross-queue or CPU-GPU). The source API determines when synchronization is needed. Metal 4's primitives determine how to express it.

References

Read the relevant Metal 4 SDK header before writing synchronization code — the headers are the source of truth for property names, types, and method signatures.

• Metal 4 SDK headers - $(xcrun --show-sdk-path)/System/Library/Frameworks/Metal.framework/Headers/ — focus on MTL4CommandEncoder.h (barriers), MTLEvent.h (events), MTLFence.h (fences)
• Apple documentation - Resource synchronization

Design Patterns

Barrier Primitives