Managing Metal4 Synchronization

---
name: managing-metal4-synchronization
description: Metal 4 explicit synchronization — barriers, fences, events, and cross-API state translation (from D3D12, Vulkan, OpenGL). Use when porting GPU synchronization, translating resource state transitions, or debugging barrier-related visual corruption.
---

# 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](https://developer.apple.com/documentation/metal/resource-synchronization)

## Design Patterns

### Barrier Primitives

Metal 4 provides three barrier types on `MTL4CommandEncoder`. The APIs use two scope levels for stage masks: