Some ideas about the Apple Metal API

After reading Metal's development documentation, in addition to some of the official claims for benefits (such as easier to understand and use the API, more direct and granular hardware control, less CPU overhead in GPU usage, etc.), some of the following are more exciting from my limited GLES development experience.

More convenient and friendly multi-threaded GPU rendering support

GLES's design, everything must be bound to a GL context, driven by the state machine controlled within the GL context, and GL context is tightly bound to the individual thread itself, making it difficult to support the construction of a good multi-threaded GPU rendering architecture, Chrome's The solution is to build a GL context proxy mechanism on top of GL, the proxy GL context allows multiple threads to create different instances, and each proxy GL context uses a Command Buffer with the real GL Context to communicate and keep in sync.

And Metal in the design of how to better support the multi-CPU thread simultaneously "using" the GPU, its Command queue/command Buffer model, although a bit like the Chrome Proxy mechanism, different CPU threads can Encode Commands to a different Command Buffer and then into the same Queue to wait for the GPU to actually execute. But Metal's built-in support is certainly more convenient, easy-to-use and efficient, and less restrictive than Chrome's package on GL.

Seamless integration of GPU rendering and computing (Rendering and Compute)

Although GLES will support Compute Shader in the future, it is hard to say whether Metal is such a seamless interface (including Command execution and resource sharing).

A unified resource memory management model that allows the CPU to directly access Metal Resource (buffer/texture) storage memory and set a clear timing for CPU/GPU synchronization

Although GLES 3 can support a GPU-controlled memory through Pixel Buffer Object, it is limited by too many limits (and because of the lack of good multithreading support in GLES itself). Android's GraphicsBuffer system/Hardware compatibility issues are stacked, performance is uneven, there is no clear cpu/gpu timing, and can only be used for specific scenarios.