看后 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 去完成。
版权声明:本文博客原创文章。博客,未经同意,不得转载。