Metal 设备与命令队列：从零搭建 GPU 指挥中心

说真的，刚接触 Metal 那会儿，我最困惑的就是设备（Device）和命令队列（CommandQueue）到底是个什么关系。你想想看，一个负责和 GPU 硬件打交道，一个负责调度任务，这两者到底怎么配合？

我在早期项目里就因为搞混了它们的作用，导致渲染线程卡得飞起。后来才明白，设备是 GPU 的抽象句柄，命令队列是 GPU 的工作管线入口——它俩是 Metal 应用的基石。

设备对象：你的 GPU 身份证

MTLDevice 说白了就是系统里 GPU 的代理对象。每个 Metal 应用至少需要一个设备，它是你创建几乎所有 Metal 资源的入口——缓冲区、纹理、着色器库、管道状态对象……都靠它生成。

核心事实：每个 MTLDevice 对应一个物理 GPU。系统可能有多个 GPU（独立 GPU + 集成 GPU），但你通常只需要一个主设备。

创建 MTLDevice

获取设备的 API 极其简单，但我建议你不要只用默认方式：

// 最简单：获取系统默认 GPU（通常是主显示器关联的 GPU）
id<MTLDevice> device = MTLCreateSystemDefaultDevice();

// 但更好的做法：列出所有可用 GPU
NSArray<id<MTLDevice>> *devices = MTLCopyAllDevices();
for (id<MTLDevice> dev in devices) {
    NSLog(@"设备名称: %@, 是否低功耗: %d", [dev name], [dev isLowPower]);
}

我在做 Mac 端 Metal 部署时踩过一个坑：MTLCreateSystemDefaultDevice 在 Mac 上返回的不一定是性能最强的 GPU。如果用户有独立显卡，它可能返回集成显卡。所以我后来改成了列出所有设备，让用户或策略选择。

我个人的建议：移动端直接用默认设备；Mac 端优先选择 isRemovable == YES 的设备（通常是独立 GPU），或者让用户配置。

设备特性 iOS / iPadOS macOS
GPU 数量 通常 1 个（集成） 1-多个（集成+独立）
默认设备选择 MTLCreateSystemDefaultDevice 够用 建议用 MTLCopyAllDevices 手动选
低功耗检测 基本不需要 isLowPower 判断是否集成 GPU

设备功能集检查

拿到设备后，第一件事是查它的能力等级。Metal 对不同 GPU 的支持差异很大：

// 检查是否支持 Tessellation（曲面细分）
if (![device supportsFeatureSet:MTLFeatureSet_iOS_GPUFamily3_v2]) {
    NSLog(@"⚠️ 此设备不支持曲面细分，需降级方案");
}

// 检查是否支持 Metal Performance Shaders
if ([device supportsFeatureSet:MTLFeatureSet_macOS_GPUFamily1_v1]) {
    MPSImage *mpsImage = [[MPSImage alloc] initWithDevice:device imageDescriptor:desc];
}

我习惯把功能检查写成一个工具方法，每次应用启动时跑一遍，根据结果切换渲染路径。否则在低端设备上调用高级特性，直接 crash。

命令队列：GPU 工作的传送带

有了设备，接下来就是创建命令队列。你可以把命令队列想象成一条传送带——你把命令缓冲区（CommandBuffer）放上去，GPU 按顺序取走执行。

// 创建命令队列
id<MTLCommandQueue> queue = [device newCommandQueue];

// 设置队列的标签（调试利器！）
[queue setLabel:@"主渲染队列"];

每个设备可以创建多个命令队列，但注意：每个队列内部是串行的——命令缓冲区按提交顺序执行。队列之间是并行的。

队列管理：别让 GPU 闲着

我在生产项目中通常维护 2-3 个命令队列：

  1. 渲染队列：负责绘制调用、帧缓冲操作
  2. 计算队列：处理后处理、粒子模拟等计算任务
  3. 资源上传队列：纹理、缓冲区上传，避免阻塞渲染

曾经踩过的坑：把所有工作塞进一个队列。如果你的渲染线程和计算线程共用同一个队列，渲染就得等计算做完——帧率直接腰斩。我当时在 Mac 上开发 Metal 计算滤镜，忘记把计算任务挪到独立队列，结果 UI 卡成幻灯片。

命令缓冲区的生命周期

命令队列管理的是命令缓冲区。每个缓冲区有清晰的生命周期：

// 1. 创建
id<MTLCommandBuffer> cmdBuffer = [queue commandBuffer];
[cmdBuffer setLabel:@"帧缓冲区"];

// 2. 编码命令（渲染、计算、拷贝）
// ...

// 3. 提交到 GPU
[cmdBuffer commit];

// 4. 等待完成（同步模式 - 不推荐在主线程用）
[cmdBuffer waitUntilCompleted];

// 5. 回调通知（异步模式 - 推荐）
[cmdBuffer addCompletedHandler:^(id<MTLCommandBuffer> buffer) {
    // GPU 工作完成，更新 CPU 端数据
}];

这里有个关键点：commit 只是把缓冲区放到队列里，GPU 可能还没开始执行。同步等待会让 CPU 阻塞，所以我主要用异步回调 + dispatch_semaphore 来协调。

同步与异步：两套调度哲学

Metal 支持两种工作模式，我用一个表格对比它们的差异：

维度 同步模式（waitUntilCompleted） 异步模式（addCompletedHandler）
CPU 阻塞 阻塞直到 GPU 完成 不阻塞，回调通知
适用场景 离线渲染、一次性计算 实时渲染、游戏循环
帧率影响 CPU 空转，资源浪费 CPU 可以提前准备下一帧
调试便利性 容易跟踪（线性执行） 需要处理好竞态条件

我绝大部分时候都走异步模式。举个例子，每帧渲染流程是这样的：

- (void)drewFrame {
    // 1. 等待上一帧完成信号
    dispatch_semaphore_wait(_frameSemaphore, DISPATCH_TIME_FOREVER);

    // 2. 创建命令缓冲区
    id<MTLCommandBuffer> buffer = [_queue commandBuffer];

    // 3. 编码渲染命令
    [self encodeRenderCommands:buffer];

    // 4. 设置完成回调，发出信号
    __block dispatch_semaphore_t sema = _frameSemaphore;
    [buffer addCompletedHandler:^(id<MTLCommandBuffer> b) {
        dispatch_semaphore_signal(sema);
    }];

    // 5. 提交
    [buffer commit];

    // 6. 立刻返回，CPU 可以处理触控、动画等逻辑
}

这里用了信号量做 三缓冲同步——CPU 最多超前 GPU 2 帧。如果完全不加同步，CPU 可能把 GPU 淹死，导致大量延迟；如果每帧都 wait，那又回到同步模式。

我的经验值：推荐用信号量控制最大在途帧数，移动端 2-3 帧，桌面端可以 3-4 帧。帧数越低，延迟越小，但 CPU 压力越大。

多队列与并发：榨干 GPU 的最后一丝性能

当你需要并行执行不同任务时，多队列策略就派上用场了。我最近一个项目里，渲染队列跑主场景，计算队列跑后处理模糊，再有一个队列专门上传贴图：

// 创建多个队列
id<MTLCommandQueue> renderQueue  = [device newCommandQueue];
id<MTLCommandQueue> computeQueue = [device newCommandQueue];
id<MTLCommandQueue> transferQueue = [device newCommandQueue];

// 渲染队列提交渲染命令
id<MTLCommandBuffer> renderBuffer = [renderQueue commandBuffer];
// ... 编码渲染 ...

// 计算队列同时提交后处理
id<MTLCommandBuffer> computeBuffer = [computeQueue commandBuffer];
// ... 编码计算 ...

// 两个缓冲区互不干扰，GPU 按硬件能力并行执行

但注意：命令队列本身不提供同步机制。如果两个队列的缓冲区需要共享资源（比如读取同一张纹理），你必须用 MTLFence 或信号量手动同步，否则会出现数据竞争。

SVG：设备与命令队列的架构关系

MTLDevice 与 MTLCommandQueue 架构图 MTLDevice 渲染队列 计算队列 资源上传队列 命令缓冲区（渲染） 命令缓冲区（计算） 命令缓冲区（上传） GPU 硬件 一个 MTLDevice 管理多个 MTLCommandQueue，每个队列串行执行，队列之间并行 命令缓冲区 commit 后进入队列，GPU 按顺序消费，CPU 通过回调或信号量同步 异步提交

这张图展示了典型的三队列策略。每个队列内部是严格串行的，但队列之间可以并行执行。GPU 硬件会根据队列优先级和当前负载来调度。

队列配置的一些实战建议

  • 不要创建超过 4 个队列——多了反而增加调度开销。我一般固定 3 个，分别对应渲染、计算、资源。
  • 给队列起名字——用 [queue setLabel:@""]，在 Xcode GPU 调试面板里一眼就能认出哪个是哪个。
  • 注意队列的活跃度——如果某个队列长时间没有提交缓冲区，系统会把它挂起。重新提交时会有短暂的唤醒延迟。

提醒一点：千万不要在主线程里等 GPU 完成。我见过太多新手在 drawRect 里写 [buffer waitUntilCompleted]，结果 UI 响应直接崩了。用回调 + 信号量这种模式就很好，CPU 在等待的时候还能处理其他事情。

嗯，关于设备与命令队列的核心内容就这些。简单总结：设备是资源工厂，队列是任务通道。理解这两个概念后，后面的渲染管线、计算管线就都好上手了。

← 上一章 📖 返回目录 下一章 →