In late 2013, Apple announced the iPhone 5s. Built into the 5s was the A7 Processor, the first 64 bit GPU for the iOS device family. It provided a decent graphical boost compared with prior devices and reflected how GPUs in mobile devices were quickly catching up to gaming consoles released just a few years prior. OpenGL, though a staple in low-level graphics APIs, didn't squeeze the most out of the A7 chip.
Seen in the next diagram, the interaction between the CPU and GPU doesn't always perform the optimal way we'd want it to for our games.
Be it textures, shaders, or render targets, draw calls use their own state vector. The CPU via the low-level API uses much of that time verifying the state of the draw call. This process is very expensive for the CPU. What happens is that in many cycles, the GPU is sitting idle, waiting for the CPU to finish its past instruction. Here's what's taking up all of that time in the API:
What Apple did with their Metal API is do these steps in a smarter fashion. Shader compilation is done during the application's load time. There's no need to reload the shaders every cycle; this was simply a relic of older hardware limitations. This is why in our previous code example, we can build more than one shader in one Metal file, while this was prohibited in OpenGL ES. State validation, though important, doesn't need to be checked every cycle. Checking the state validation can be set to happen only when new content is loaded.
Note
Even with Metal's advantages, this is why it's recommended to store 2D animations in SpriteSheets. We mentioned SpriteSheets back in our discussion of on SpritKit. They are a collection of sprites fitted onto one texture. The graphics pipeline then only has to deal with one version of that content. Internally under the hood of SpriteKit, the GPU then doesn't have to do as many state vector calls compared to having each character animation being placed on its own separate texture.
The last process for the CPU is when it sends the information out to the GPU for processing. This is going to be done during each draw call, and in either Metal or Open GL ES, it will still be this process that will happen the most frequently. Here is the result of this internal, low-level restructuring done in the Metal API:
As we see in the diagram from WWDC14, there are up to 10 extra draw calls that can be added during the render cycle! We can use that time saved for other processes instead of extra draw calls, such as more physics or AI in our games.
Note
The cycle diagrams shown are from the original Metal API announcement at WWDC2014 and used a frame rate of 30 fps. If developing for VR where 60 fps or greater is necessary for a working game, these numbers are halved. Either way this is rather impressive for mobile device GPUs. Search online for games made in Metal and you'd be impressed. With this much room to add more to our game during each render cycle, there's no reason not to have an impressive game at the full 60 fps. Additionally, as of iOS 9, the SpriteKit and SceneKit frameworks by default are backed by Metal. Even if the Metal API is too much to understand, we can still utilize these render saving benefits from what we already learned about these frameworks.