I helped fix sleep-wake hangs on Linux with AMD GPUs
nyanpasu64.gitlab.io
nyanpasu64.gitlab.io
I am not sure how correct this assumption is. S3 is supposed to cut power to everything but RAM, but for example Gigabyte Aorus motherboards are notorious for an NVMe SSD sleep bug that randomly prevents the system from properly sleeping or waking.
This is fixed by adding the following udev rule:
# Generic PCIe fix for sleep bugs by preventing wakeup from any PCIe port
ACTION=="offline", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
# Gigabyte sleep fix by preventing wakeup from problematic PCIe port, depends on motherboard model
ACTION=="offline", SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0x43bc", ATTR{power/wakeup}="disabled"
1. cat /proc/acpi/wakeup (you'll have to trial and error your way through the wakeup devices if it isn't immediately clear)
2. cat /sys/class/pci_bus/*/*/yourWakeupDevicePci/uevent | grep PCI_ID
3. prepend "0x"
udevadm info --attribute-walk /dev/whatever
Or if you want to shellscript it (less reliable than letting udev do it for you and needs to be done via systemd service file or another automation):
# Gigabyte sleep fix, port depends on mobo model
/bin/bash -c 'if grep 'RP05' /proc/acpi/wakeup | grep -q 'enabled'; then echo 'RP05' > /proc/acpi/wakeup; fi'";
You also have to make sure it applies after the default rules.
You can check if the rule applies once you have everything set up by doing an `udevadm` attribute walk of your SSD device (not partition), and then following it up all the way up the device tree until you see your specific device port (target fix) or PCIe driver subsystem (general fix). Then check if "power/wakeup" is set to "disabled". If it is set to disabled, something else is keeping your device awake on sleep.
For that you can check /proc/acpi/wakeup, and there's also a specific systemd invocation (that I forgot) you can do that shows if your device slept, how long it slept, how much battery was drained, and if your device woke-up, slept or failed to resume, it'll give you a reason.. to the best of its ability.
The system seems to go into sleep state just fine, it just freezes when waking up again
> The system seems to go into sleep state just fine, it just freezes when waking up again
The behavior differs per device. Some sleep but freeze on wakeup, some immediately wakeup after sleeping, and some (like mine) will go to sleep 98% of the way, but the fans keep spinning. That was a dead giveaway for me that the bug was triggered. I suspect that on some systems, either the fans turn off and the system succeeded to getting to sleep 99% of the way, or the fans are so quiet that people do not notice them. And from that limbo state you can only recover with a hardware shutdown or interrupting power.
I'm fairly certain this issue is fixable for you as well, either with only this fix (and we just have to find the proper port(s), or with this fix and for whatever other device might be causing this issue.
ACTION=="add", KERNELS=="0000:00:01.1", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled"KERNELS=="0000:00:01.1" sounds like an interesting way to do it, since you can target separate functions of the PCI device (in this case: domain 0, bus 0, slot 1, function 1).
Any further insight you might have on these Aorus wakeup issues? In particular, it seems the wakeup in my case is coming from `.../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6` which does not really mean anything to me.
(Additionally I also previously disabled PCI wakeup buses and haven't touched it again since it's working)
hope that info helps.
ACTION=="offline", KERNELS=="0000:00:45.6", ATTR{power/wakeup}="disabled"
Running `echo GPP0 >> /proc/acpi/wakeup` into a systemd unit at boot solved the issue for me... except the first sleep after a boot would always wake back up immediately.
I applied your udev rule and that issue seems to be resolved as well!
I remember there being some strange interaction with the wakeup behaviour being toggled otherwise. But this could be due to me being on NixOS.
If you don't add "RemainAfterExit", the service will run at every boot, because after a reboot it is considered "inactive. This will execute your shell code, which effectively toggles wakeup.
"RemainAfterExit" is meant for unit files that change the state of your system. After running once, the service will be considered "active", until you manually deactivate it, which will execute whatever you might have set in "ExecStop".
"Type=Oneshot" is necessary for "RemainAfterExit".
In this case I still would prefer doing it via udev though. I've made it my rule of thumb to evade shell scripting wherever feasible, because it usually ends up being more brittle, and more prone to footgunning :)
You would hope that you could probe the hardware to see if it really is in sleep or not, or that re-waking the hardware would not cause issue if it never went to sleep.
Also I would expect that you could send a sleep command to the PCIe device, then try to sleep the bus itself. The to wake you would bring back the bus and then wake the device.
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/2125#note_17...
So while I get the "I just want sleep to work, dangit" attitude (it really should just work, to be honest) the fact is that it barely does work. Seriously, it took this long to realize that VRAM contents may not fit into RAM entirely, so powering down the drives that hold the swap should probably be postponed to the last moment.
It's pretty unbelievable when you think about it. The majority of mainstream progress on application state management has taken place in mobile operating systems and essentially amounts to the expectation that you won't lose data if and when your process is unexpectedly forced to terminate without user interaction. Forget actually picking up exactly where you left off.
And as long as I'm complaining. All of my sshfs mounts tend to break if I sleep-wake as well. Remounting them generally doesn't fix programs that were using them (for obvious reasons) - I usually have to manually close and reopen all of that.
Just change your fucking habits and move on. I think Linus Tech tips complained about a unrelated but equally frustrating issue with S0 awhile back. I fucking hate S0 it makes me feel like tech companies are trying to force people to have always on computers by removing S3 support entirely from modern hardware.
Power control is the kind of stuff that benefits from very tight integration, and PCs just don’t have that.
Firmware is seen by most vendors as a pure cost to minimize, so you get a fragmented market full of subcontractors delivering the bare minimum that is considered “working”. Manufacturers also know most people aren’t going to use a big part of the functions they’re supposed to provide to OSes, and no one is really checking them, so it’s very common for devices to have only partial support for things they supposedly do.
What's strange is that it never used to be a problem. There are five Windows laptops floating around our house at various times (mixture of work and personal) and suspend works properly on none of them. Oddly, it works on my personal laptop with Debian Stable almost every time, failing maybe 1/25 times. Other distros are about the same as Windows.
I don't get why S3 sleep had to die for this, but it did.
If you want your device to be off, power it off.
On Linux, you can run a systemd unit file that will trigger `rfkill` on sleep and a different `rfkill` invocation on wake and you effectively dodge all that crap because the laptop isn't connected to WiFi and thus will sit around realizing its spinning its wheels and wil shut down further down the s0 chain.
> I don't get why S3 sleep had to die for this, but it did.
Worse yet, the dirty little secret is that many laptops that offer both S0 and S3 will actually drain more energy in S3 than in S0 because the S3 mode has had poor QA.
(Any link to the video/docs for turning it off?)
For me, I have an M2 and no issues. Was worried about v1 issues (same for VisionPro—will wait until v2)
I'd rate my OpenBSD X1 as not terrible too. Not as smooth as MacBook but adequate.
My work mac (M1 Pro) occasionally locks up and reboots when waking from sleep too, at about the same frequency.
Always wondered why this was such a difficult problem to solve, seemingly irrespective of operating system. (Linux has never been acceptable or reliable in this respect, IME, regardless of distro and hardware configuration.)
Or Macintosh. My $DAYJOB Macbook sleeps properly about about 2 out of 10 times, at best. Most of the time it fails to sleep and by the next morning when I open it up, the battery is dead. :-(
For comparison, my System76 laptop running PopOS! sleeps perfectly, every time with no issues. shrug
You use a 20+ year old[1] PowerPC laptop for your dayjob?
Talk about hardware longevity!
[1]: Powerbooks were last made in 2006 I think?
Important to remember that work laptops typically install all sorts of crap spyware and fleet management software that causes the system to misbehave. That’s not as much on Apple although not protecting their brand against such software is on them.
Good thing it's all fixed now, eh! /s
Now its like an elderly nursing home patient who wakes up several times and raids the kitchen to eat all the time.
The fall of a once great OS is sad to see. I guess AI matters more to Microsoft than their Core OS nowadays.
I would have expected it with a cheap clone, but this was a fully integrated computer made by the same people who designed and manufactured the processor itself!
I can't remember if it ever fixed it - maybe after a year or two there were finally newer EFI and graphics drivers that fixed the issue, but maybe it never did? In the end I ended up getting a newer machine to replace it anyway and it became my home server so just runs Proxmox now and doesn't need to ever sleep...
There was, eventually, a Windows program which hacked the device to take it out of sleep. But I had no Windows OS on it. Before I got around to installing enough Windows, the NUC died for other reasons :-(
It also plagues Windows on custom PC builds, even when there are vendor drivers. Not every component plays nicely with suspend states, ASPM, C-sates, load line calibration, etc. And while often the capability exists natively to address issues (in BIOS, Linux, etc), how many people know how to start looking?
The computer locking up when said devices are removed and not properly going to sleep then is a different (much worse) issue
powercfg /lastwake
So it's not really a problem unless you really wanna do deeper sleeps.
the way I parsed this was; so it's not really a problem unless you want to use your computer the way you want to use it.
I get things are complicated, and hardware support is a mixed bag. But it doesn't have to be this way.
Chasing "real sleep" gives me nothing but pain. Also Android devices "sleep" fully awake so it's really "what people are doing".
Microsoft also went that route with the Surface line, it just never sleeps.
It seems like it's basically hardware whack-a-mole at this point. The only reason Apple does it reasonably well is they control more of the stack and they support less hardware. The only reason Windows does it better than Linux is they have more eyes on it.
I've interacted with him countless times on the kernel mailing list and bug tracker, he's literally paid by AMD to work on Linux support for AMD's consumer desktop hardware.
I have been buying System76 for about twenty years now, and this is has not been an issue for me either.
A lot of workarounds that are suggested for various issues are also not really viable. Some of the workarounds involve turning off different power-saving modes; however, the point of enabling sleep is often to increase the amount of usable time between charges, and turning off these power-saving modes can often dramatically shorten battery life.
But getting sleep to work (even S0ix!) is not impossible.
I have a bunch of handheld AMD 7840U and AMD 8840U devices that I have installed Arch Linux on: GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3, OneXPlayer X1 Ryzen. These devices were not designed with Linux support in mind. I would be very surprised if the companies that made them ever tested them with Linux. Yet with just a small amount of work (generally fiddling with `/proc/acpi/wakeup` and `/sys/devices/*/*/*/power/wakeup` to disable sources of spurious wakeups,) I have gotten essentially flawless S0ix support (… on all but the newest OneXPlayer X1 Ryzen.)
(In general, out-of-the-box stock Linux kernel support on these devices is fantastic. Touchscreens work, pen input works, wifi and Bluetooth work well. The only gap I've seen is fingerprint reader support.)
I suspect that given how small these manufacturers are (and how small their production batches must be,) there's much less extreme-customization and tight-integration of components. This is visibly evident in the form-factors of these devices, which many millimeters thicker than they might otherwise be. (Of course, these devices are primarily advertised to a gaming audience who are eager to avoid the thermal-throttling that happens with ultra-thin devices like Surface Pro…) I partially suspect that the lack of extreme-customization, the lack of tight-integration, and the smaller production batches means that the manufacturers make much more conservative choices in components. Maybe this explains the exceptional Linux support?
Thanks
It's been solid on every business Thinkpad for a long long time for me and consistently seems people on Windows with the same models have more sleep problems.
One more point for rust in the kernel. Just can't happen if you're required to handle a Result type.
But of course defaults matter and the kernel’s rich history of not modernizing coding practices is going to work against improvements in C land. Ironically, it’s that same resistance that frustrates the Rust devs so much because their resistant to even cleaning up their own subsystems or putting down markers documenting how the subsystems are supposed to work.
Maybe https://github.com/llvm/llvm-project/issues/74205 would help once it trickles down into the kernel, but I suspect that people are still going to choose to do this manual overloading of the pointer instead of using types for safety.
In contrast to that, running MacOS in a VM is heaven. Figuring out how to pass my iPhone through to Xcode took as long as the initial setup.
This is really great work and will serve as a reference point for debugging similar issues in the future. Pretty happy about systemd's debug-shell feature, I had no idea that existed. I don't think my X670E Steel Legend board has a serial header anywhere on it, though. How do modern built-in serial ports work, anyway? Are they attached off of the chipset PCIe lanes?
Something that's also very useful when trying to dive into the Linux kernel is that there's a bunch of great talks discussing Linux kernel subsystems from conferences like FOSDEM and Linux Plumber's Conference which you can usually find recordings of online. For example, there's this one for TTM, the memory subsystem that most of the desktop GPU DRM drivers use:
- Overcommit. Linux will "overcommit" memory: allocations will succeed when there's no memory, and then hang when the page is actually mapped if no physical pages are available (to my understanding.) Windows NT doesn't do this. Not sure exactly how macOS/XNU handles it.
- The OOM killer. Because allocations don't fail, to actually recover from an OOM situation the kernel will enumerate processes and try to kill ones that are using a lot of memory, by scoring them using heuristics. The big problem? If there isn't a single process hogging the memory, this approach is likely to work very poorly. As an example, consider a highly parallel task like make -j32. An individual C++ compiler invocation is unlikely to use more than a gigabyte or two of memory, so it's more likely that things like Electron apps will get caught first. The thrashing of memory combined with the high CPU consumption of compilers that are not getting killed will grind the machine to a near-complete halt. If you are lucky, then it will finally pick a compiler to kill, and set off a chain reaction that ends your make invocation.
There are solutions... Indeed, you can use quotas with cgroups. There's tools like systemd-oomd that try to provide better userspace OOM killing using cgroups. You can disable overcommit, but some software will not function very well like this as they like to allocate a ton of pages ahead of time and potentially use them later. Overcommit fundamentally improves the ability to efficiently utilize all available memory. Ultimately I think overcommit is probably a bad idea... but it is hard to come up with a zero-compromises solution that keeps optimal memory/CPU utilization but avoids pathological OOM conditions by design.
Is there any other sensible way to do this though? It would be quite inefficient to constantly call mmap for additional small(ish) pieces of memory. In effect overcommit just means that until the page is actually written to it hasn't really been allocated. (Aside: I believe a malloc implementation that zero'd out blocks on allocation would fail abruptly rather than later in case that happens to be what bugs you about it.)
Additionally how do you suppose fork should be implemented efficiently? Currently it performs copy-on-write. At minimum you'd need a way to mark pages as "never going to write to these, don't reserve space for a copy". Except such an API is either very awkward to use in practice or else leaves you with some very awkward edge cases to deal with in your program logic.
> You can disable overcommit, but some software will not function very well
Yeah about that.
Chromium runs (AFAIK) 1 PID namespace per tab. On my machine right now it reports 1.1 TiB virtual memory with a little over 100 MiB resident per tab. 1.1 TiB mapped PER TAB. Of the resident I have no idea how much is actually unique (ie written to following the initial fork).
Firefox is much more reasonable at a mere 18 GiB mapped per PID.
However I think you'd need per-thread signal handlers for that to work sensibly. Which the kernel supports (see man 2 clone) but would require updates to (at least) posix and glibc.
It would probably also be nice to have a way to allocate pages without writing to them. Currently we have mlock but that prevents swapping which isn't desirable in this context.
This is most likely a trick for garbage collection or memory bug hardening or both. Haskell programs also map 1tb.
Thanks for the video about TTM, I'll watch it when I have a chance.
With zstd you can turn 8GB of RAM into 20GB of 'RAM' without much issue. or 16GB into 40GB. Hell, if you're feeling adventurous (and Android does this, so its very stable) you can overcommit your memory past 100%.
Yes. It's horrendous to put it mildly. Linux does not handle OOM conditions properly.
I know I can set up a few guardrails with cgroups. I know I can also install earlyoom. I know I can increase swap or use zram. In the end these are all fundamentally just nasty hacks that might spare one once in a while. They do not fix how these conditions are handled. Please do not offer these as solutions.
I've seen LUKS volumes mount themselves read-only because the kernel couldn't allocate memory in dm_crypt, for the love of god just kill something in userspace. The current state is utterly unacceptable and I'm tired of all the excuses.
"offline" is for when your system turns off or suspends, "online" vice versa, and "remove" is self-explanatory.
If you go with "offline", I'd look into hard disconnecting the monitors. This might cause monitor rearrangement (= you'll need to manually assign) or blinking on laptop bootup. Might also stop any charging. But that could be mitigated by checking the "subsystems" attribute.
If you go with "online", you probably need run some sort of clean-up / refresh script or rule
If you go with "remove", you'll need the same clean-up / refresh script.
It'll take some trial-and-error, but it'll be satisfying once it works. Also highly recommended to check the NixOS repositories and official wiki and Arch wiki to see if your laptop or monitors have workarounds for their quirks.
This is always my favorite part of debugging.
Honestly, it's one of the main issues I wish the Linux community would take a closer look at and finally fix!
https://learn.microsoft.com/en-us/windows-hardware/design/de...
The nearest thing to a sleep issue is that the screen is visible for a fraction of a second on some wakeups before the lock screen covers it. A bit of a privacy issue.
Good to see that AMD might be getting better support, in part because of its growing popularity.
Also I got curious about your blog (haven't heard about Zola, recently migrated my own blog over to a newer version of Grav, which is a flat file CMS with no DB) and saw your post about looking for a new job. Hope things work out for you, stay safe!
why nobody else sees this?
Every smartphone does suspend/resume thousands of times each day, it has to be nearly 100% reliable feature and it is, otherwise users would be majorly pissed off.
Source: I work on windows power management and I know system engineers at apple.
So controlling the entire stack isn't enough. There has to be a desire to do better, as well as technical competency.
in my experience with OnePlus, it aggressively kills and/or throttles applications that you want to be running in the background (e.g. fitness trackers or even audio players) even when you put them on the battery allowlist.
at the same time, my iPad just randomly decides to drain all of its battery even when it's been sitting unused without any apps installed. I don't have this problem on Pixel devices. (you do get this problem as soon as you install some misbehaving apps but that's something you've done to yourself)
hw.acpi.lid_switch_state=S3In fact, it turned out that a BIOS update that happened in the middle of my issues broke sleep functionality for the whole machine for a few months, so that wasn't even my fault.
That seems like a bit of trouble if you have 16GB of system RAM and a 24GB GPU.
During suspend, for graphics cards, GPU VRAM needs to be transferred to system RAM.
However, during high memory usage scenarios the VRAM + RAM usage could exceed system memory -- this would ordinarily involve system swap coming into play and handling the temporarily out of memory issue. However system swap was already deactivated when it came time to suspending the AMD card causing all sorts of problems.
The fix was asking the GPU to evict its VRAM to system RAM via the hook ("suspend prepare") before swap was deactivated in linux kernel.
AFAICT (from the behavior) something isn't properly saved/restored and communicating with the GPU (the mouse cursor is a hardware cursor thus needs to send commands to the GPU to update its position) causes some sort of issue. Switching to another virtual terminal that is running in text mode probably forces the driver to reset its graphics state. Of course that is just my assumption based on what i see going on.
Weirdly enough this only happens after i replaced my RX 5700 XT with a RX 7900 XTX so it might be something GPU (or GPU arch) specific.
I've been considering plugging my laptop and see if there is something i can figure out (GPU aside the PC is usable, but i guess if this a kernel side thing i'd need a second computer connected to it to debug it), but as this isn't something i've tried before (though i know someone who has and said it isn't anything special) my annoyance still hasn't gone over the "i need to get to the bottom of this" threshold :-P.
It'd be nice if 6.14 fixes the issue, though i am not sure as i rarely have more than 1/3rd of the system RAM (32GB) in use and VRAM (24GB) barely goes above 1-2GB of use outside games. But this post might be helpful in diagnosing the issue next time it happens :-).
"We have tried to solve these issues case by case, but found that may not be the right way. Especially about the unbalanced irq reference count, there will be new issues appear once we fixed the current known issues. After analyzing related source code, we found that there may be some fundamental implementation flaws behind these resource tracking issues.
So we try to fix those issues by two enhancements/refinements to current device management state machines."
You can just use screen for that and have a working terminal with color support et al.
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?
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...
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).
Anyone have other tips for this type of thing? I did try upgrading drivers/kernels already
If memtest shows a specific memory region as failing, swap out sticks to check which it is, and buy a new one. (Or if you're on a tight budget, you can disable that region with kernel boot options.)
If memtest gives errors in lots of places, might be a bad overclock. Loosen timings or give it more voltage.
Honestly, I'd always do that as the first option. In most cases you can still get years of life out of that stick of ram (but do check regularly, like after a week and then double the interval every time if it didn't get worse).
I would also recommend running it on one memory slot only (do this one by one).
Recently it happened that even a multi-day memtest run did not catch the defect in one of my ram slots.
But when I emptied it, all the gpu driver problems immediately stopped.
The symptom was a crash followed by garbage on screen and a "zzzz" sound. Sometimes followed by a shutdown.
I'll try it.
Lol, I remember.
@nyanpasu64, do you think enabling nvidia-suspend/nvidia-resume services will do the trick? I didn't go through the codefix in the above post in detail, but it looks like the fix is to raise a relevant notification to all listeners in the suspend_prepare() method for amdgpus, not nvidia.
Running Ubuntu 24.10.
If anyone has ideas what could fix this I'd really appreciate it. The machine is dual booted with Windows, and there sleep works without issue, so it's clearly possible, as it was for years before that on Linux as well.
$ uname -a
Linux hostname 6.13.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 02 Feb 2025 01:02:29 +0000 x86_64 GNU/Linux
NVIDIA-SMI 570.86.16
Driver Version: 570.86.16
CUDA Version: 12.8
alias off='xset dpms force off && await.sh && xset -dpms'
$ cat ~/bin/await.sh
#!/usr/bin/env bash
xinput test-xi2 --root 2>&1 | \
grep --line-buffered -m 1 'EVENT type 2 (KeyPress)' &> /dev/null
Adding nomodeset to the GRUB configuration was another suggestion:
# grep vmlinuz /boot/grub/grub.cfg | head -1
linux /vmlinuz-linux root=UUID=... rw nomodeset quiet resume=UUID=...
An older Thinkpad with secondary NVIDIA dGPU used to work fine, but now every time the monitor powers off (or is unplugged), Xorg instantly dies with no apparent logs.
So I don't have to do anything special to recover except login over again and start a whole new MATE session.
Check your logs if you have a message "Freezing user space processes failed". You can disable this behaviour with the instructions at https://github.com/systemd/systemd/issues/33626#issuecomment...
I am not clever/experienced enough to solve my own issues with sleep-wake hangs on Linux at work.
I’ve instead opted to work around it. I use Firefox, Obsidian, and Tmux with Neovim for all my work. Tmux has resurrect and a plugin that saves my entire terminal state automatically every few minutes.
I also have a command that automatically sets up my i3wm/regolith windows exactly how I like.
Basically if I run `wkup`, I’m exactly where I was, down to the line of code open on NeoVim, Firefox tab, and dev server or cargo running.
https://github.com/lkdm/dotfiles/blob/main/bin/executable_wk...
Hope it helps you out
Fortunately, although that's not the focus of this article, system hibernate is WAY more reliable than system sleep in Linux due to the way it works.
Use system hibernate if your SSD is fast enough. It works better than system sleep and isn't a ton slower.
Great work!
2025 finally Linux on the desktop
Just to make sure I'm not griping over something long fixed, I took a quick look and instantly found someone with a very similar issue to the one I ran into happening on a semi-recent kernel: https://community.amd.com/t5/pc-drivers-software/linux-amdgp...
It looks to me that if you want to have a working computer under Linux, it's worth the extra cost to avoid AMD.
I think this is a rather hasty conclusion. The popular opinion is the opposite. If you want a working computer under Linux, it's worth it to avoid NVIDIA, especially for laptops. Sure, AMD are not perfect contributors to the kernel, but they are contributing more than NVIDIA[0]. NVIDIA has made some moves recently[1], but the AMD GPUs are still better integrated. Notably since the Steam Deck had been released, the situation has been excellent.
Anecdotally, my laptop with an NVIDIA GPU has many issues that have persisted over the years with things like high idle power draw or frequent straight up crashes, or incomplete Wayland support. My 3 devices that have an AMD GPU (1 desktop, 2 laptops) however, have been working flawlessly from day 1.
[0] https://www.phoronix.com/news/NVIDIA-Contributions-2010s-Ker...
The community has been able to come up with a workaround for some older cards but the problem persists even in their current cards.
I have first-hand experience across five distinct AMD 7840U and AMD 8840U devices that near-perfect, out-of-the-box Linux-support (with stock kernels and no dodgy kernel flags!) is possible. This includes support for S0ix suspend.
https://news.ycombinator.com/item?id=43083669
I don't doubt it when people recount their bad experiences with AMD devices; however, my experience should serve as an existence proof that it's not a universal experience.
In the case of each device mentioned in the comment above, I followed a standard installation procedure from an Arch installer USB. I use only stock kernels: linux, linux-lts, and linux-zen. For almost all of the devices, the only kernel flags I pass are for enabling hibernate or handling FDE. (In one or two cases, the devices have portrait displays that have been installed for use in landscape-orientation. These need an `fbcon=rotate:…` kernel flag.)
In all but one case (the OneXPlayer X1 Ryzen) everything (except fingerprint readers) works flawlessly. In the case of the OneXPlayer X1 Ryzen, there is an intermittent issue with hang on suspend, but that may have gone away with a recent kernel update. If not, I'll probably come back to this blog post and see what I can do…
However, they have published docs on their hardware. For instance, https://gpuopen.com/amd-gpu-architecture-programming-documen... Their driver is also in-tree: https://wiki.archlinux.org/title/AMDGPU
It may or may not be as good as Intel. I don't have the depth of experience there right now.
It looks like AMD and Intel GPUs should be roughly similar in terms of support / out of the box experience on Linux, but AMD will have better performance.
Nvidia is still super proprietary, so it will generally have more headaches and hoops to deal with.
So, generally, I rank them by default:
1. AMD 2. Intel 3. Nvidia
Unless there is a reason (firmware or configuration differences for Intel/AMD needing to run/develop CUDA code for Nvidia) I try to stick with that. I've not yet had an AMD laptop though.