Genuine question: How is GPU accelerated rendering more prone to crashes than just doing it on the CPU?

Also, on macOS, Apple practically controls the whole stack too. Putting macOS on something that isn’t their hardware is a challenge.

Side note: there’s errata on the Intel CPUs, but I’m sure there’s also some (confidential) errata on the “A” series processors in iDevices. If iOS can work around the errata, why couldn’t macOS?

On Mac and Windows, you are relying on Drivers to do the work where you dont have the source code. While the piece of code is running on OpenGL or Direct X or Metal. And on top of all that there is a composition layer.

Modern GPU drivers is an insane piece of optimisation / engineering. But the complexity means you will never quite grasp the problem when things go wrong. In the early days of Firefox or Thunderbird it is recommended you turn off Hardware Acceleration whenever you see Font or Graphics rendering problem. While a lot of these have been fix ( or migrated ), it is still popping up from time to time.

There was a recent thread on HN ( I cant find it sorry ) Firefox asked for help on a GPU rendering bug that they have a hard time figuring out what's wrong.

On iOS, Apple owns the whole thing they can figure out what's wrong and fix it. As Apple write their own GPU drivers.

The GPU is a whole separate computer, running code independently, with its own clock scaling and power management. Having two separate things that can break is more complexity than one thing that can break. And having to have the two communicate in order to do delicate procedures like waking from sleep increases complexity dramatically.

Also, on many Macs, it's actually three separate things. There is the CPU, the integrated GPU, and the discrete GPU. The system switches between the two GPUs dynamically based on load and whether the system is plugged in.

How's that different from each CPU core?

The CPU cores are all (more or less) identical. The GPU has a completely different architecture.

> May be it is better on iOS since Apple owns the whole stack from Metal to Drivers to actual GPU

This goes the other way than what you would think.

Owning the whole stack lets you reach through abstraction layers. This can be good for, say, efficiency. You don't have to assume the implementation of another component could work in multiple different ways, you can look inside it and do something that only works with the specific implementation you're actually using.

It tends to be bad for reliability. Having clean interfaces between things makes them easier to reason about, because they're independent components instead of a giant ball of spaghetti. Each component only has to consider the other component's published interface and not have to worry about every detail of its internals. It's "do one thing and do it well" vs. "nothing is ever guaranteed not to change in any way at any time."

The latter gives you greater flexibility at the cost of greater instability and fragility.