Performing calculations on a GPU

At a glance

Project structure

Source bundle/
└── MetalComputeBasic/
    ├── main.m
    ├── add.metal
    ├── MetalAdder.m
    └── MetalAdder.h

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; MetalAdder 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["MetalAdder"]
    N3["command-line MetalAdder orchestration"]
    N4["parallel add compute kernel"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

MetalComputeBasic/main.m:32 — feature handoff or setup anchor

        MetalAdder* adder = [[MetalAdder alloc] initWithDevice:device];
        
        // Create buffers to hold data
        [adder prepareData];
        
        // Send a command to the GPU to perform the calculation.
        [adder sendComputeCommand];

Interpretation

This is the dominant control/data path: platform code composes MetalAdder; that object controls command-line MetalAdder orchestration; GPU-visible work ends in parallel add compute kernel. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    main *-- MetalAdder : adder

Ownership evidence

MetalComputeBasic/main.m:32 — main creates for a local scope adder

        MetalAdder* adder = [[MetalAdder alloc] initWithDevice:device];
        
        // Create buffers to hold data
        [adder prepareData];
        
        // Send a command to the GPU to perform the calculation.
        [adder sendComputeCommand];

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

Shader boundary reference

MetalComputeBasic/add.metal:11 — representative GPU entry/helper

kernel void add_arrays(device const float* inA,
                       device const float* inB,
                       device float* result,
                       uint index [[thread_position_in_grid]])
{
    // the for-loop is replaced with a collection of threads, each of which
    // calls this function.
    result[index] = inA[index] + inB[index];
}

Design patterns

Naming conventions

• Role suffixes make ownership visible: MetalAdder.
• Method names describe setup or encoding actions: initWithDevice, prepareData, sendComputeCommand, encodeAddCommand, generateRandomFloatData, verifyResults.
• Shader entry points use stage/operation names: add_arrays.
• 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; MetalAdder is the owner of command-line MetalAdder orchestration.
• Treat parallel add compute kernel as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is main → adder; 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