關于 Apple Metal API 的一些想法

在看完 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 可以通過 支援一塊 GPU 控制的記憶體可供 CPU 直接通路，但是畢竟限制太多，用途有限（另外也由于 GLES 本身缺少良好的多線程支援）。而 Android 的 GraphicsBuffer 系統/硬體相容性問題成堆，性能參差不齊，沒有明确的 CPU/GPU 同步時機，也隻能用于特定場景。