I didn't wade through that entire thread, but the most recent post has a specific set of circumstances:

https://forums.macrumors.com/threads/constant-kernel-panics-...

> After waking from sleep and running a process using hardware accelerated video decoding / encoding, the UI will freeze for a couple of seconds, then starts working again, then freezes again, and so on. The mouse can still be moved but the UI is non-responsive. Eventually, after waiting for long enough, a kernel panic occurs and the machine reboots.

How to reproduce:

1. Use any Navi10 or Navi14 graphics card inside a Mac Pro 2019, eGPU case or use a MacBook Pro 16.

2. Open Video Proc or any other app utilizing hardware video acceleration (e.g. Safari playing Youtube, exporting with FCPX / iMovie).

3. Run the video acceleration test in Video Proc, start playing a H.264 / H.265 video in Safari or export a H.264 / H.265 file from FCPX / iMovie.

4. Put the machine to sleep.

5. Wake it again and re-test video acceleration.

6. If machine doesn't freeze, repeat the cycle from step 4.

7. Repeat this until the UI starts freezing / video acceleration stops working.

8. Eventually the machine will kernel panic after several minutes.

I’ve had this happen on my work MBP (13” non-touch bar, BT magic keyboard and trackpad and HDMI monitor connected via a cheap USB-C hub) a handful of times. Really have no idea what motivated it.

I don't even let my screens turn off anymore; these days I get this weird thing where after waking the monitors up the monitor does not get a signal, but if it is plugged in, the mouse jumps around at like 2fps on the main display as if there's some weird interrupt denial of service going on.

To fix this, I have to restart just to use my monitor again.

I have that problem too and I tried that, but then the OS forgot the setting during an update, and now I'm back to unplugging and replugging my adapter every time I grab a coffee or take a phone call.

External display wakeup problems have been an issue on many generations of MacBook Pro going back to PowerBooks (even with Apple displays). Very annoying!

I experienced this issue using an HDMI to DVI adapter from my 2018 Mac mini to a Dell Ultrasharp display. After purchasing a replacement cable that didn't remedy the problem, I discovered that it's a known issue.

The fix was to use a USB-C -> DisplayPort cable (using DisplayPort via USB-C alternative mode). It appears that the HDMI port can't be used with a DVI converter. DVI ports have been replaced by DisplayPort, HDMI, and DisplayPort for some time but it was still a disappointment.

One of the reason why I dont like GPU acceleration in general. And this isn't just on macOS, Windows, Firefox, Chrome.

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

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.