I hit a similar issue in OpenGL on macOS about 10 years ago. We had a fairly complex set of draw calls. It worked fine on high-end machines, and was perfectly u

I hit a similar issue in OpenGL on macOS about 10 years ago. We had a fairly complex set of draw calls. It worked fine on high-end machines, and was perfectly usable, if a bit slow, on mid-range machines, but on low-end iMacs with crappy Intel graphics cards, it would cause the machine to panic and reboot. It ended up being that the draw calls filled up the smaller command buffer on the low end card, and the driver would crash. In talking with the implementors, they explained the situation, so I asked, "How do I determine that I'm filling up the command buffer?" The answer was basically, "The size of the command buffer is an implementation detail and there's no way to query OpenGL for it or for the size of the commands you're adding." Gee, thanks! We ended just breaking up the draw calls into more smaller calls and it solved the problem, but this entire bug was such an ordeal. Thankfully we're moving away from OpenGL and things are a bit more sane in Metal. Had I not had access to the OpenGL team at Apple at the time, there's no way I would have been able to figure out what was going on. I'm not sure if I would have thought to do the same work in smaller batches.