[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...

[nyanpasu64]

As I understand, KWin does call glGetGraphicsResetStatusARB(), and on Nvidia GPUs, sleep-wake (or opening apps if it crashed the GPU) would cause KDE to detect a graphics reset and print "Desktop effects were restarted due to a graphics reset" (https://github.com/KDE/kwin/blob/10c04995c1f9f82ddbd6610e5e0...). I haven't used Nvidia GPUs in years and don't know if this is still an issue. I think many apps don't check for graphics resets?

I'm not sure if residency is relevant here; the Microsoft link indicates that eviction makes memory inaccessible from the GPU to make room for other memory, which explains why Linux uses the same name for "backing up" VRAM before sleep (through the same underlying mechanism).