Sample CodemacOSReviewed 2026-07-21View on Apple Developer

Running inline ML operations in a shader with Metal 4

At a glance

Item	Summary
Purpose	Multiply matrices across multiple GPU cores with inline tensor operations.
App architecture	Objective-C host code with Metal shaders; `Command-line main` hands work to `MatrixMultiplier`, which owns command-line matrix multiplier before inline ML shader operation and writeback.
Main patterns	Command-line composition, Compute pipeline, Host-shader data contract
Scope	High-level review of 8 scanned source files and 7 detected declarations; build assets are omitted.

Project structure

Source bundle/
├── Entry point/
│   └── main.m
├── Matrix multiplier/
│   ├── Shaders.metal
│   ├── MatrixMultiplier.h
│   └── MatrixMultiplier.m
└── Matrix/
    ├── Matrix.m
    ├── Matrix+TensorUtilities.h
    ├── Matrix+TensorUtilities.m
    └── Matrix.h

Structure observations

The entry/composition boundary and renderer or operation boundary are separate in the source; MatrixMultiplier is the principal feature coordinator.
GPU-specific logic stays in Metal shader files; shared headers bridge host/shader layouts where present.
The tree above is intentionally pruned to composition, resource, and shader files.

Overall architecture

flowchart LR
    N1["Command-line main"]
    N2["MatrixMultiplier"]
    N3["command-line matrix multiplier"]
    N4["inline ML shader operation and writeback"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Entry point/main.m:43 — feature handoff or setup anchor

    MatrixMultiplier *multiplier = [MatrixMultiplier new];

Interpretation

This is the dominant control/data path: platform code composes MatrixMultiplier; that object controls command-line matrix multiplier; GPU-visible work ends in inline ML shader operation and writeback. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    main *-- MatrixMultiplier : multiplier

Ownership evidence

Entry point/main.m:43 — main creates for a local scope multiplier

    MatrixMultiplier *multiplier = [MatrixMultiplier new];

Owner	Object or state	Relationship	Mutation authority
`main`	`multiplier` / `MatrixMultiplier`	Creates for a local scope; the diagram uses composition because construction is source-visible.	The declaring scope performs setup and replacement.
`MatrixMultiplier`	Feature-specific framework and Metal resources	Operation-local calls or stored state; exclusive lifetime is not assumed beyond cited evidence.	Feature setup/encoding code controls mutation and command submission.

Class and protocol design

Type	Responsibility	Depends on or conforms to	Source
`MatrixMultiplier`	encapsulates the feature operation and its framework/GPU resources.	`NSObject`	`Matrix multiplier/MatrixMultiplier.h:19`
`Matrix (TensorUtilities)`	adds tensor-extent element counts and index/coordinate conversion helpers used by inline Metal ML operations.	`Matrix`, `MTLTensorExtents`	`Matrix/Matrix+TensorUtilities.m:10`

No local protocol abstraction is present; the sample uses concrete framework, operation, or model types at this boundary.

Access control

Symbol	Access	Verified effect	Design reason
`MatrixMultiplier`	`header-visible`	available to translation units that import the header; this is not Swift public.	Keep the usable surface no wider than the collaboration requires. (`Matrix multiplier/MatrixMultiplier.h:19`)
`MatrixMultiplier implementation details`	`implementation-only`	native helpers, stored state, or registration code stays out of the imported header contract.	Hide native implementation details from importing translation units. (`Matrix multiplier/MatrixMultiplier.m:1`)
`Shaders entry points`	`Metal library boundary`	host code resolves named shader entry points; Swift access modifiers do not apply.	Expose only named shader entry points needed by pipeline creation. (`Matrix multiplier/Shaders.metal:46`)

This sample does not use Swift private, fileprivate, or public for its native boundary. Objective-C/Objective-C++ use header versus implementation placement, C++ uses access specifiers/linkage, Python uses module conventions, and Metal entry points cross a compiled-library boundary; these are not Swift access levels.

Logic ownership and placement

Logic	Owning type or file	Why it lives there
Encapsulates the feature operation and its framework/GPU resources	`MatrixMultiplier` — `Matrix multiplier/MatrixMultiplier.h:19`	The type’s callbacks and stored state align with this responsibility.
Command-line matrix multiplier	`MatrixMultiplier` / `Entry point/main.m:43`	Keeps Metal/framework setup and encoding out of entry or lifecycle code.
Inline ML shader operation and writeback	`Matrix multiplier/Shaders.metal:46`	GPU-parallel code remains in the Metal compilation boundary.

Shader boundary reference

Matrix multiplier/Shaders.metal:46 — representative GPU entry/helper

kernel void

Design patterns

Pattern	Source evidence	Purpose or tradeoff
Command-line composition	`Entry point/main.m:43`	Makes the sample’s command-line matrix multiplier an explicit, reviewable boundary.
Compute pipeline	`Entry point/main.m:43`	Makes the sample’s command-line matrix multiplier an explicit, reviewable boundary.
Host-shader data contract	`Entry point/main.m:1`	Shared indices/structs and matching bindings couple host encoding to shader signatures deliberately.

Naming conventions

Role suffixes make ownership visible: MatrixMultiplier.
Method names describe setup or encoding actions: data, matrixWithRandomRows, initWithRows, initWithData, initFromTensor, multiplyWithMatrix, isEqualToMatrix.
Shader entry points use stage/operation names: matrix_multiplication_kernel.
Names favor concrete domain roles and target-local types; no broad public library namespace is introduced.

Architecture takeaways

Keep Command-line main focused on composition; MatrixMultiplier is the owner of command-line matrix multiplier.
Treat inline ML shader operation and writeback as a separate execution/compilation boundary with explicit resource and data-layout contracts.
The verified ownership edge is main → multiplier; broader exclusive ownership is not inferred.
Access-control rationale follows concrete language boundaries rather than translating every header or shader symbol into Swift terms.

Source map

Source file	Architectural role
`Entry point/main.m`	entry point or feature implementation
`Matrix multiplier/Shaders.metal`	entry point or feature implementation
`Matrix/Matrix.m`	`Matrix`, `Matrix`
`Matrix multiplier/MatrixMultiplier.h`	`MatrixMultiplier`
`Matrix multiplier/MatrixMultiplier.m`	`MatrixMultiplier`
`Matrix/Matrix+TensorUtilities.h`	`Matrix`
`Matrix/Matrix+TensorUtilities.m`	`Matrix`
`Matrix/Matrix.h`	`Matrix`

Official Apple documentation