Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Gamescope, the microcompositor from Valve that is used on the Steam Deck that can also be used on desktop Linux, just got a major upgrade.

What exactly does Gamescope do? Think of it like a piece of software that handles display output. So for the Steam Deck, it's what actually displays your games in Gaming Mode. For desktop Linux you can use it to run games directly to force resolution, AMD FSR, NVIDIA Image Scaling, border-less window, full-screen window and more.

Developer Joshua Ashton has been hacking away on HDR support, some of which has shipped in SteamOS 3.5 Preview but another fun addition recently is work on support for ReShade. The documentation for Gamescope has now been updated to note it supports a "subset of Reshade effects/shaders" and so this provides an easy way to layer "shader effects (ie. CRT shader, film grain, debugging HDR with histograms, etc) on top of whatever is being displayed in Gamescope without having to hook into the underlying process".

On their Fediverse social media page, they mentioned with some screenshots:

I got Reshade shaders working under Gamescope/SteamOS today!

Which means we can get Lilium/EndlesslyFlowering's amazing HDR Analysis shaders to work on all HDR games on SteamOS.

This will be super useful for users and developers.


Credit - Joshua Ashton

Some other notes from the changes:

There is currently no way to set the value of uniforms/options, they will just be their initializer values currently.

Using Reshade effects will increase latency as there will be work performed on the general gfx + compute queue as opposed to only using the realtime async compute queue which can run in tandem with the game's gfx work.

Using Reshade effects is highly discouraged for doing simple transformations which can be achieved with LUTs/CTMs which are possible to do in the DC (Display Core) on AMDGPU at scanout time, or with the current regular async compute composite path. The looks system where you can specify your own 3D LUTs would be a better alternative for such transformations.

Pull requests for improving Reshade compatibility support are appreciated.

Article taken from GamingOnLinux.com.
24 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
4 comments

rustybroomhandle Sep 18, 2023
I do like that this will supported at this level, but when they say "subset" it likely will not include anything that, for example, uses depth maps or anything like that. For my own purposes I will stick to ReShade installed per game. I have an easy file copy-paste preset I use to easily enable it in a game.

I don't use vkBasalt for this mainly because when last I checked it also did not provide the config overlay.
Lofty Sep 18, 2023
I tried re-reading that but im a little bit confused on the "HDR Analysis shaders to work on all HDR games on SteamOS" why is an analysis tool required for a game that already has HDR and conforms to the HDR output standards, don't we just read that and display HDR ? or is this something cooler like what xbox was offering where the system can kind of create HDR maps from SDR games in a much more effective manner than the existing fake HDR shaders that just boost contrast and mess with the gamma slightly. Maybe it was just the way it was written.


Last edited by Lofty on 18 September 2023 at 9:36 pm UTC
Phlebiac Sep 19, 2023
Quoting: Loftywhy is an analysis tool required for a game that already has HDR

Considering he is working on HDR support, I'm pretty sure it's useful for debugging purposes.
MayeulC Sep 19, 2023
Quoting: Loftywhy is an analysis tool required for a game that already has HDR and conforms to the HDR output standards, don't we just read that and display HDR ?

Well, that could be an invaluable tool for developers as well. And regarding "just displaying HDR", I think it's more complicated than that, as you have to map the colorspace of the application to the one of the screen (think HDR->SDR but with each screen supporting a different subset of the colorspace). It's probably useful for compositor developers as well.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.