Apple Metal API Docs | Apple Metal Shading Language Docs
Took a few minutes this late evening to see what Apple's Metal API actually looks like. Some notes on a quick first look (could be missing stuff),
Single queue for the GPU.
Queue changes between three modes {gfx, compute, copy}.
API offers parallel command buffer generation.
Command buffers get enqueued first which provides ordering.
Then committed later which marks completion.
No command buffer reuse (must regenerate each frame).
Only trackable completion is at command buffer boundary.
Ability to create views of textures.
Ability to create texture views of buffers.
Standard numbered binding slots for resources, but all stages share same binding table.
Cached state objects.
State objects: {texture, buffer, sampler, shader library, compute, framebuffer, pipeline, depth/stencil}.
Pipeline state: {vertex fetch, shaders, blend state, framebuffer format}.
Ability to create the expensive pipeline state objects asynchronously.
Framebuffer attachment options at start of rendering: {clear, load, don't care}.
Framebuffer attachment options at end: {store, MSAA resolve, don't care}.
Thoughts
Feels a lot like the design of DX11 with desktop GPU features removed, but with working parallel command buffer generation. Seems like pipeline state covers all the graphics state which requires a run-time recompile or patch of shader binaries or complex configuration of the graphics pipeline. I guessing the pipeline state is where they get lots of perf compared to ES. I'm assuming this hardware has no fixed function blending, so I'm not sure why they did not just remove blend state and simply require shaders to use framebuffer fetch and framebuffer store? Looks like the primary advantages of this API over their existing ES API: pre-compiled shaders, super aggressive caching of state objects, working parallel command buffer generation, compute, and finally really optimizing the driver.
Took a few minutes this late evening to see what Apple's Metal API actually looks like. Some notes on a quick first look (could be missing stuff),
Single queue for the GPU.
Queue changes between three modes {gfx, compute, copy}.
API offers parallel command buffer generation.
Command buffers get enqueued first which provides ordering.
Then committed later which marks completion.
No command buffer reuse (must regenerate each frame).
Only trackable completion is at command buffer boundary.
Ability to create views of textures.
Ability to create texture views of buffers.
Standard numbered binding slots for resources, but all stages share same binding table.
Cached state objects.
State objects: {texture, buffer, sampler, shader library, compute, framebuffer, pipeline, depth/stencil}.
Pipeline state: {vertex fetch, shaders, blend state, framebuffer format}.
Ability to create the expensive pipeline state objects asynchronously.
Framebuffer attachment options at start of rendering: {clear, load, don't care}.
Framebuffer attachment options at end: {store, MSAA resolve, don't care}.
Thoughts
Feels a lot like the design of DX11 with desktop GPU features removed, but with working parallel command buffer generation. Seems like pipeline state covers all the graphics state which requires a run-time recompile or patch of shader binaries or complex configuration of the graphics pipeline. I guessing the pipeline state is where they get lots of perf compared to ES. I'm assuming this hardware has no fixed function blending, so I'm not sure why they did not just remove blend state and simply require shaders to use framebuffer fetch and framebuffer store? Looks like the primary advantages of this API over their existing ES API: pre-compiled shaders, super aggressive caching of state objects, working parallel command buffer generation, compute, and finally really optimizing the driver.
