Windows has fully user space graphics drivers since Vista. Linux still utilizes kernel modules and I'm not aware of plans to move everything to user space. It's honestly pretty cool that entire graphics driver can crash under Windows and all that happens is a bit of flickering.
Are you sure? It seems like WDDM has a user-mode "User-mode display driver" - which looks to me like the HW-specific part of Mesa: it's invoked by the D3D runtime - and a "Display miniport driver", which is in the kernel.
That said, no doubt Linux's ability to reset drivers is way, way behind... We're coming up on 20 years since Windows could recover from a graphics driver reset reliably without losing the desktop, and only partial hacks exist on Linux today.
I really need to get around to building a sample HTML page to show how unsafe having WebGL enabled on Linux browsers is. One long shader, and your desktop is a goner.
It doesn't matter much what Linux you use. Rather what is your desktop environment? (KDE Plasma, Gnome, sway etc.)
On KDE for example there is a shortcut to restart the compositor, which might fix your issue.
But in general you might have luck "restarting" it by switching the tty. You do that by pressing CTRL + ALT + some function key between F1 and F8 (the standard gui tty number depends on the distro). Try to switch to a non gui tty and then back.
+1 to ctrl-alt-fsomething (start at f1 and go up to move through the different virtual terminals). once in a while there are graphics problems which this will fix.
If you're using GNOME Shell on X you can reload the shell (and all of its extensions) with alt-f2 and then in the "Run a command" dialog that appears type r and hit enter. Unfortunately this doesn't work in GNOME on Wayland.
If the kernel runs into a oops it can recover and you won't notice anything except a nasty looking error in dmesg. If it runs into a panic you need to hard reboot the system as it can't continue to run.
amdgpu has a recovery mechanism built in that can be triggered using sudo cat /sys/kernel/debug/dri/N/amdgpu_gpu_recover where N is the number of the DRI device in question. You could bind a shortcut to doing that I presume.
I have an AMDGPU machine - a hateful HP laptop with a Vega 6 chipset - and the display regularly goes garbled when I switch VTs. I too am looking for a way to "reset the graphics card" and cat /sys/kernel/debug/dri/N/amdgpu_gpu_recover ain't it: it resets it alright, but after that you get a frozen image and X is dead.
Maybe Wayland survives that but Xorg definitely doesn't.
The only reliable graphics card reset solution I've every found was to close then reopen the laptop to force the machine to go to sleep, then wake up and go through the restart rigmarole cleanly. I wish there was a way to do that sleep-wakeup routing with a keyboard shortcut, but I haven't found one.
I think the real solution is to buy a decent replacement laptop though.
Yeah, Xorg (and the apps) will likely die. There is a wayland protocol in the works to be able to gracefully handle driver resets but I'm not sure on its implementation status.
I have a case. My PC at work is a HP Celeron PC. For some reason the Intel HD drivers go nuts in Office and the whole ribbon just turns black. That spreads to all other applications and makes every signel menu bar just a black rectangle. The only solution to this is to restart the driver. No driver or windows update could fix it.
Maybe sudo systemctl restart gdm? That's not quite the same as it restarts gnome display manager.
When your computer freezes and you can't get to a tty with Ctrl+alt+F4 then it likely encountered a kernel panic. A panic is not recoverable. In some senerios I've seen the amdgpu module run into a kernel oops which is recoverable. It doesn't really effect the desktop other than a studder as the kernel reinitializes in the background.
If your system is freezing start by checking RAM and then try a different GPU. Its likely a hardware issue
It's turned off by default in a lot of distros these days but it can be turned back on. It used to be that editing /etc/X11/xorg.conf was recommended but because file inclusions are a thing these days, it makes more sense to create a new file /etc/X11/xorg.conf.d/enable-killing-xserver.conf:
Then restart the X server (which, these days, is pretty much a reboot). Or, going through the x.org documentation archives, it looks like you could dispense with the config files and run setxkbmap -option "terminate:ctrl_alt_bksp" in a terminal session and that'll do the same thing.
There is a proposal to consider making a Wayland extension where programs can sit around and re-attach to a fresh, non-deaded display server. KDE is much closer to having a working version.
On Linux, if a graphical app does not crash from this, that is a rare exception.
On windows, if a graphical app crashes from that, that is an exception.