在看完 Metal 的开发文档后，除了官方所宣称的一些优点外（比如说更容易理解和使用的
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 同步时机，也只能用于特定场景。
关于 Apple Metal API 的一些想法,布布扣,bubuko.com