ReflexiveTransativeClosure

Yes, more or less (although now I think about it larger factors should probably work fine I think). I think the omission is probably explained to some extent as gamescope was primarily developed for the Steam Deck (so, limited battery and a small screen), where users are very unlikely to be downsamping in most cases. For anyone who wants this in their own builds, the simplest version (which I'm not sure is strictly linear, but is linear-ish, and should work with any scaling factor supported by the bicubic PR) is a one-line patch on the bicubic branch; just open src/shaders/cs_bicubic.comp and add the following to the start of textureBicubic() [here]: return texture(splr, texCoords); Hopefully, when/if the bicubic PR is merged it shouldn't be too hard to add this as an extra mode.

Okay I made a mistake here, gamescope could (and appears to in my testing) apply a very limited form of bilinear filtering in very specific circumstances, which isn't really by design. I think that you would have to be downscaling from an internal resolution which is a non integer factor of the output. This likely won't be as good as proper bilinear (not-least because of the resolution requirements) but it might be that this effect is sufficient for you -- choosing the right internal resolution would be a matter of trial-and-error. (Another possibility is that DGVoodoo2 is doing downsampling -- but I don't think that's what's happening given the configuration described) You're right, given gamescope is working at all, the behaviour of the downsampling should be identical on AMD and Nvidia. I also attach a gamescope build with a linear-ish filter. It's something I hacked together in half an hour though, so it won't be perfect (I'm not a graphics programmer), and only works for exactly 2x scaling. The result is somewhere in-between unfiltered and bicubic for aliasing and softness. The keybinds are different too (it's based on my downstream tree, sorry), it's meta+b for no filtering (blit), and meta+j for bilinear. meta+k gives somewhat broken bicubic. (Also, if you press meta+n (sample nearest) by accident, you should press meta+l (sample linear) to get everything back to normal). Unfiltered: Hacky bilinear: gamescope.zip

Also I forgot to say -- It's off by default, so you will have to have pressed meta+k at least once to see any difference (in particular those alpha-test shrubs in the distance are a good tell that it's working). If it looks a bit muddy, be careful that you're downscaling from an exact multiple of the display resolution, up to 4x per axis (beyond that it will run into other problems), so up to 7680x4320 from a 1080p output.

You're not doing anything wrong, I'm afraid the reason it isn't working is that gamescope doesn't support proper downsampling. There's a work in progress version with good-quality downsamping at https://github.com/ValveSoftware/gamescope/pull/740 but that patch will only be merged at the discretion of the maintainer (Valve and their contractors). I've compiled a version which should work on your machine with that patch (copy it to /usr/local/bin and Lutris should pick it up). If you press (super/windows key)+k while the game's running it should toggle the downsampling filter. gamescope.zip

sudo setcap -r /usr/games/gamescope should do that I think.

Given vkcube is working, it seems likely that the drivers are fine (or at least, working as intended). Re-installing the drivers is quite a drastic step (which can potentially break the entire system) so perhaps best avoided until you're sure it's absolutely necessary. The output from this one looks very promising. It is getting further than the others without encountering the vkCreateDevice error, so something's working at least. The undefined symbol error is to do with how libraries work on Linux. It's possible that the person who compiled gamescope for you was using a different distribution, with a different version of the SDL2 library. Sadly this often won't work properly, so you won't be able to use that compiled version of gamescope. There is a PPA with an up-to-date gamescope build which shouldn't have this issue (and should also be new enough to have decent Nvidia support, so shouldn't give any of the previous errors either). You could try that one instead, you'd have to run: sudo mv -T /usr/games/gamescope /usr/games/gamescope.old (To make sure the compiled version you copied to games doesn't get in the way) sudo mv -T /usr/bin/gamescope /usr/bin/gamescope.old (To make sure the compiled version you copied to bin doesn't get in the way) sudo apt remove gamescope (Remove the old ppa gamescope. This step shouldn't be needed -- but apt can get confused so it's best to run it anyway) sudo add-apt-repository --remove ppa:samoilov-lex/gamescope (Remove the out-of-date ppa) sudo add-apt-repository ppa:ar-lex/gamescope (Add the new in-date ppa) sudo apt install gamescope (To install the new version) The add-apt-repository commands should ask you to press enter to confirm. The apt remove command should confirm it will remove gamescope (and perhaps ~5 more packages, but not 10s or 100s). The apt install one should tell you it is installing a few new packages. Then, try running gamescope -f -- glxgears (or if that doesn't work, try /usr/games/gamescope -f -- glxgears) **, which will hopefully work (or at least not give any of the previous issues). If that works, then you're most of the way there (as xrogaan observes, there might still be issues with Lutris, but these shouldn't be too hard to fix. ** The newer ppa installs gamescope to /usr/games/.

To add to this a little, for Nvidia the privileges needed should be that the process is running with CAP_SYS_NICE [0]. Gamescope doesn't try to use the priority feature (which helps performance but isn't essential) if CAP_SYS_NICE isn't set for this reason [1]. It would definitely be a good idea (when you've checked that which gamescope gives the right output) to check, getcap /usr/games/gamescope which will print "/usr/games/gamescope cap_sys_nice=eip" if CAP_SYS_NICE is set, and nothing otherwise. If getcap does print that line, then you can try running, sudo setcap -r /usr/games/gamescope to remove the capability and prevent Gamescope from using the feature. You should then get a line in Gamescope's output when running a programme saying: "No CAP_SYS_NICE, falling back to regular-priority compute and threads. Performance will be affected.". If getcap does not print that line, you can instead run, sudo setcap 'cap_sys_nice=eip' /usr/games/gamescope which will set CAP_SYS_NICE, and should allow the priority feature to work (if the driver sees sense). That should mean the "... falling back to regular-priority ..." message isn't printed when you run Gamescope. [0] https://forums.developer.nvidia.com/t/linux-solaris-and-freebsd-driver-470-42-01-beta/181536 [1] https://github.com/ValveSoftware/gamescope/blob/56a799827d005425a5764d1572b87efd9ace10b9/src/rendervulkan.cpp#L811

First, the vulkan: vkCreateDevice failed could imply an issue with the driver. If you run 'vkcube' (which should already be installed with vulkan-tools), do you get a window with a spinning cube in it? If not (i.e. you get a vulkan error): it's a driver issue. Otherwise, the version of gamescope in ppa:samoilov-lex/gamescope is quite old, so using that newer version is a good idea. I've checked that version you've attached, and it's recent and works fine for me. Just to check you're running the right version, could you run 'which gamescope'? It should print '/usr/games/gamescope'. If not: that could be the problem. If all of that's okay then it's something less obvious, but it's always worth eliminating the obvious stuff first.