[fowl2]

I guess "hibernating" (writing VRAM to swap) works better than expecting userspace to gracefully handle device resets. One linear read vs. a thundering herd of processes re-initialising, decompressing, etc. should be more predictable/reliable at least.

I do wonder however how much VRAM is "volatile" - ie. framebuffers - and could just be thrown away. And web browsers seem to handle GPU resets just fine, so maybe they could opt-in?

[nyanpasu64]

I didn't mention in the article but the Nvidia drivers at one point would drop VRAM rather than preserving it, leading to corrupted RGB noise textures in window managers and browsers (and potential crashes though I don't think I encountered them). I suggested doing this on the AMD bug tracker (https://gitlab.freedesktop.org/drm/amd/-/issues/2362#note_20...), but the amdgpu developers weren't interested.

[fowl2]

Oh wow didn't really expect anything other than whole device loss. Just returning garbage does sound bad.

Do you know if they tried to communicate with clients and were just ignored/not implemented or if the APIs just don't support it?

A quick search indicates that "residency"[1] exists, but no idea the extent it's useful/implemented.

[1] https://learn.microsoft.com/en-us/windows/win32/direct3d12/r...