It looks like the NVreg_PreserveVideoMemoryAllocations setting is disabled, which is currently expected to result in errors in Chrome and Firefox when VT switching. Can you please try enabling vidmem preservation and trying again?
I know it seems counterintuitive, but having working vidmem preservation for suspend & resume allows the driver to use a lighter-weight mechanism for VT switching too.
or (I think) by setting nvidia.NVreg_PreserveVideoMemoryAllocations=1 on the kernel command line.
It’s not enabled by default because it requires S3 suspend & resume to go through the nvidia-sleep.sh script. That works if the nvidia-suspend, nvidia-resume, and nvidia-hibernate systemd units are installed and enabled and the system is suspended through systemd, but not all Linux distributions use systemd and enabling vidmem preservation by default on those would cause suspend to fail and be perceived as a regression.
Distributions that install the driver through a package are in a better position to ensure that the appropriate systemd units are enabled and can be more confident about enabling it by default. Looking at your bug report log, it does look like the systemd units are already enabled and activating during suspend, so enabling NVreg_PreserveVideoMemoryAllocations=1 should work fine.
I don’t think Windows drivers use any storage for suspend/resume, yet the Linux drivers need this feature. How come Windows doesn’t fall apart on suspend/resume?
My GPU supports Video Memory Self Refresh which means I can enable NVreg_EnableS0ixPowerManagement=1. What are the pitfulls of using it if I don’t care about the increased power consumption in suspend? I don’t think it’s more than 1W for my GTX 1660 Ti.
I’m not familiar with the details so take this with a grain of salt, but my understanding is that on Windows, the WDDM core code takes care of saving and restoring video memory data itself.
This vidmem preservation code migrates all video memory contents to system memory that is (depending on the filesystem specified by NVreg_TemporaryFilePath) backed by physical storage pages. So if you have a lot more vidmem allocated than you have free system RAM to store it, and your filesystem is backed by a slow disk, it could make suspend & resume significantly slower. On the other hand, this mechanism also works with system hibernate since the vidmem contents are copied to non-volatile storage.
S0ix should achieve the same end result without having to transfer anything by keeping the GPU’s video RAM contents where they are. So if the extra power consumption is okay with you, then you should be able to achieve faster suspend / resume times.