大约 Apple Metal API 一些想法

看后 Metal 的开发文档后，除了官方所宣称的一些长处外（比方说更easy理解和使用的 API。更直接和精细的硬件控制，降低 GPU 使用过程中的 CPU 额外开销等等），从我有限的 GLES 开发经验看来，下面一些方面更让人兴奋。

更方便和友好的多线程 GPU 渲染支持

GLES 的设计，全部东西都必须跟一个 GL Context 绑定。由 GL Context 内部所控制的状态机驱使，而 GL Context 又跟单个线程本身紧密绑定在一起，导致非常难支持构建一个良好的多线程 GPU 渲染架构，Chrome 的解决的方法是在 GL 之上构建了一套 GL Context 的 Proxy 机制，Proxy GL Context 同意多个线程创建不同的实例。而每一个 Proxy GL Context 内部使用一个 Command Buffer 跟真正的 GL Context 进行通讯和保持同步。

而 Metal 在设计时就考虑了怎样更好地支持多 CPU 线程同一时候“使用“ GPU，它的 Command Queue/Command Buffer 的模型尽管有点类似 Chrome 的 Proxy 机制。不同的 CPU 线程能够 Encode Commands 到不同的 Command Buffer，然后放入同一个 Queue 里面等待 GPU 的真正运行。

可是 Metal 的这样的内建的支持当然比 Chrome 在 GL 上面的封装来的更方便，易用和高效，也没有那么多限制。

GPU 渲染和计算的无缝整合（Rendering and Compute）

尽管 GLES 未来也会支持 Compute Shader，可是是否能做到 Metal 这样无缝的衔接（包含 Command 的运行和资源的共享）就比較难说了。

统一的资源内存管理模型，同意 CPU 直接訪问 Metal Resource （Buffer/Texture） 的存储内存。并设定了明白的 CPU/GPU 同步时机

尽管 GLES 3 能够通过 Pixel Buffer Object 支持一块 GPU 控制的内存可供 CPU 直接訪问，可是毕竟限制太多，用途有限（另外也因为 GLES 本身缺少良好的多线程支持）。而 Android 的 GraphicsBuffer 系统/硬件兼容性问题成堆。性能參差不齐。没有明白的 CPU/GPU 同步时机，也仅仅能用于特定场景。

简而言之。Metal 让 CPU/GPU 之间的协作更紧密和高效，同意 CPU 通过许多其他方式，使用更灵活 GPU。我们投入了大量的其他任务的 GPU 去完成。