Running a machine learning model on the GPU timeline

At a glance

Project structure

Source bundle/
├── Entry point/
│   └── main.m
├── Matrix multiplier/
│   ├── MLMatrixMultiplier.m
│   ├── MLMatrixMultiplier+PipelineCompilation.h
│   ├── MLMatrixMultiplier+PipelineCompilation.m
│   ├── MLMatrixMultiplier+TensorSetup.h
│   ├── MLMatrixMultiplier+TensorSetup.m
│   └── MLMatrixMultiplier.h
└── Matrix/
    ├── Matrix.m
    └── Matrix+TensorUtilities.h

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; MLMatrixMultiplier is the principal feature coordinator.
• GPU/framework work is encoded through native implementation code rather than a standalone .metal file.
• The tree above is intentionally pruned to composition, resource, and shader files.

Overall architecture

flowchart LR
    N1["Command-line main"]
    N2["MLMatrixMultiplier"]
    N3["matrix objects and MLMatrixMultiplier encoder"]
    N4["Metal 4 machine-learning pipeline on a command buffer"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

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

    MLMatrixMultiplier *multiplier = [MLMatrixMultiplier new];

Interpretation

This is the dominant control/data path: platform code composes MLMatrixMultiplier; that object controls matrix objects and MLMatrixMultiplier encoder; GPU-visible work ends in Metal 4 machine-learning pipeline on a command buffer. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    main *-- MLMatrixMultiplier : multiplier

Ownership evidence

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

    MLMatrixMultiplier *multiplier = [MLMatrixMultiplier new];

Class and protocol design

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

Access control

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

Design patterns

Naming conventions

• Role suffixes make ownership visible: MLMatrixMultiplier.
• Method names describe setup or encoding actions: init, loadMetalPackage, configureWithMatrix1, encodeAndRunModelInference, productTensor, data, matrixWithRandomRows.
• Shader entry points use stage/operation names: no standalone Metal shader entry point in this archive.
• 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; MLMatrixMultiplier is the owner of matrix objects and MLMatrixMultiplier encoder.
• Treat Metal 4 machine-learning pipeline on a command buffer 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

• Official Apple documentation