They have changed the filenames and installation instructions since:

dlssg-to-fsr3 has been tested in Cyberpunk 2077 and The Witcher 3 only.

dlssg-to-fsr3 may be obtained from: https://github.com/Nukem9/dlssg-to-fsr3

================================ ===== Install instructions =====

1. Right click on “DisableNvidiaSignatureChecks.reg” and select “Merge”. Click “Yes” when the dialog opens.

2. Locate your game’s installation directory. For Cyberpunk 2077, this would be the folder containing Cyberpunk2077.exe.

3. Copy “dlssg_to_fsr3_amd_is_better.dll” and the new “nvngx.dll” to your game’s installation directory.

4. Done. Launch the game. You’ll see a message box on startup.

================================ ==== Uninstall instructions ====

1. Right click on “RestoreNvidiaSignatureChecks.reg” and select “Merge”. Click “Yes” when the dialog opens.

2. Delete “dlssg_to_fsr3_amd_is_better.dll” and “nvngx.dll” in your game’s installation directory.

And there is already a mod that replaces Nvidia Frame Generation with FSR3 in games like Cyberpunk 2077, The Witcher 3 and others: https://github.com/Nukem9/dlssg-to-fsr3/releases

Has anyone gotten this to work in Linux/Proton?

I guess that’s a bit better than the original command in question. But from what I understand it’s still unnecessary and there is simply no need to force the refresh. A regular pacman -Syu is all you need and will refresh all databases that need it.

You could install the linux-lts kernel alongside the one you have already installed to have the option to just boot into that one when a kernel update seems to be the problem.

Another thing would be to look into backup solutions that execute automatically when updating your system. Personally I have my system on BTRFS subvolumes and a package called snapper to manage the snapshots (backups). Alternatively the package timeshift gets mentioned a lot when discussing backup solutions.

Otherwise you did exactly what I have done to fix almost every issue I ever had. Downgrading the likely culprit and updating again a bit later.

I’ve wondered about that as well. Especially since websites seem to know which operating system one is running anyway. Sadly I can’t say I know enough about this to have an informed opinion.

I’ve used that package as well for a while. And depending on ones needs it is perfectly usable even for gaming. In this regard noticing a difference to the closed variant is difficult. And they’ve recently added G-Sync support.

The only reason I switched back is that at the time sleep/suspend support wasn’t implemented yet. I think it still isn’t, is it? Granted waking successfully from sleep to a functioning graphical desktop is hit or miss for me even with the closed driver variant.

Very basic, but incredibly useful. Love it.

I just upgraded and didn’t have any issues. I’m not experienced in this regard at all. But just to be sure, did you execute the following after the upgrade?

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi

sudo grub-mkconfig -o /boot/grub/grub.cfg

Assuming of course your grub setup doesn’t differ from mine. These two commands are all I know about grub troubleshooting…

I’m no authority on any of this. But from what I think I understand I can tell you that you don’t need to worry about this. RT/DLSS won’t work any different or worse when games are going to run on native Wayland.

Yes, I’m on Wayland (Sway). I haven’t tested any native games. But I think RT/DLSS doesn’t care about Wayland or XWayland.

That being said, for now every game you run via Wine/Proton is running on XWayland (if one is on Wayland). They are in the process of merging code for native Wayland to Wine/Proton bit by bit. But it is going to take a while before everything is in place and Wine/Proton doesn’t need XWayland anymore. But as I’ve said, from what I understand this isn’t an issue for RT/DLSS at all.