4 ms·
Blame Apple. They have the worst graphics stack when it comes to stuff like this. Most GPUs are not pre-emptable (maybe that's changing?). Because they are not
by tokyodude 8y ago
Blame Apple. They have the worst graphics stack when it comes to stuff like this.
Most GPUs are not pre-emptable (maybe that's changing?). Because they are not pre-emptable if you give them something to do they will do it until finished. There is no interrupting them, saving state, switching to something else like with a CPU.
Microsoft realized this and so Microsoft built into the OS a timeout. If the GPU is given something to do and doesn't come back in a few seconds then they reset the GPU (like shut the power off and turn it back on, or rather send a PCI reset). You need to be aware of this in Windows programming if you have data you need on the GPU. Most games don't and can just re-upload their data if told their data was ejected but some GPGPU calculation will at least get told "sorry, GPU reset, start over"
Apple didn't implement anything like that in OSX (now MacOS) for the longest time. The entire OS is built around the idea that all apps are well behaved (LOL). If a single app gives the GPU 30minutes of work to then the GPU is going to do 30 minutes of work and your option was only hold the power button.
They tried retrofitting in a timeout but AFAICT there's just too many parts of the OS that expect no one will ever hog the GPU and it filters back to CPU land when the CPU tries to do something (queue drawing some windows) and the GPU doesn't respond for .5 a second, 1 second, 20 seconds, etc and stuff piles up etc...
Linux had (has?) exactly the same problem. I don't know how much progress has been made on either MacOS nor Linux to deal with this.
Now comes WebGL which you guys won't like but basically any page can give your GPU something that takes a few minutes to run and your machine (if it's not Windows) may crash. The mitigating factor is it doesn't help the bad guys. It's not like they can steal your info. The most they can do is convince you never to visit their site again so it's a mostly self correcting problem. The hard spots are if the person making the site was targeting a top end GPU and you visit with a low-end GPU.
There are really only 2 real solutions. The OSes need to handle the fact that GPUs are non-preemptable or we need preemptable GPUs.
Some will argue get rid of WebGL. I'd argue the issue is mostly self correcting and that Google Maps is pretty awesome and it gets that awesomeness from being able to render with the GPU. There's plenty of other 2D and 3D visualizations WebGL enables. So I'm happy to live with the self correcting problem for the benefits while I wait for pre-emptable GPUs for the real fix.
This is actually one place where I'm surprised there are cloud GPUs since they'd have the same issue. I've never used one but they must have some way of being reset. They must also not be shared? Or you just have to accept that some other process on the machine can completely hog the machine.
- t0astbread 8y agowouldn't cloud providers just bill you to death if you hogged their machines?
- gammagoblin 8y ago>Linux had (has?) exactly the same problem. I don't know how much progress has been made on either MacOS nor Linux to deal with this. All my AMD GPUs have been issued GPU resets for years. I know that in 2013 my Radeon 5870 (the card I had at the time) was issued soft resets, which was logged in dmesg as a success. The problem with that is that whatever program caused the GPU lockup would continue to run (unless it crashes, which is frequently the case) until the kernel had reset the GPU so many times, the only option left is a hard reset. On Windows, the way GPU lockups are dealt with is also by resetting the GPU, and it's the same there too, if it keeps locking up several times within a certain time span the kernel panics and you either get a BSOD or a complete system lockup.
- pcwalton 8y agoNewer GPUs have scheduling. See https://twitter.com/jhaberstro/status/1090816578298335233 https://twitter.com/jhaberstro/status/1090816578298335233