ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
23.96k stars 1.05k forks source link

Force games to bypass compositor #8025

Closed Jaskowicz1 closed 3 weeks ago

Jaskowicz1 commented 3 weeks ago

Feature Request

I confirm:

Description

I'm not 100% sure if this is actually meant to be a thing or not, however, I've noticed that some games feel slow sometimes because of compositor (one specific game is Old School Rally, however, it's not specific to a game).

Disabling compositor removes any potential stuttering (games feeling like 30 fps but they are actually running at 60/120/240 fps).

This is an issue on any Linux device it seems (tested on Debian 12 and Steam Deck with Proton 9.0-2 and Proton Experimental), however, it's more noticeable on a monitor with higher refresh rates (as you'll very quickly go from a nice smooth experience to a jarring slow feeling as if you're at 30fps despite it still running at whatever your monitor may be at or higher if you aren't using VSync).

I'm also not too sure if this is out-of-scope for Proton or if it's a-okay, please do inform me! I'd also be happy to maybe PR it if the idea of blocking compositor isn't opposed (again, do inform me if this should be for Proton or steam-runtime).

Justification

Some apps may need compositor for transparent windows, forcing compositor to be disabled in wine would break those apps (EA's app comes to mind) so it wouldn't be ideal to block it for every app through wine.

Risks

Turning Compositor off completely already causes some things to break (firefox for example), so, apps may break slightly if ran through gaming mode and aren't full-screen, however, I can't see why a game wouldn't be full-screened (or windowed borderless) in gaming mode.

kisak-valve commented 3 weeks ago

Hello @Jaskowicz1, this would be an abuse of the desktop environment that Proton is running on top of and Proton also can't reliably know how to restart the desktop environment's compositor.

Jaskowicz1 commented 3 weeks ago

@kisak-valve That's fair, however, that still leaves some games suffering from this issue where games feel slow but are running at a high FPS on Steam Deck and other machines where users don't know how to get around this issue.

Whilst I can live with doing shift+alt+f12 or telling KDE to suspend the compositor and resume it after, it's annoying to have to modify my launch parameters just to fix the issue on some games where it seems more present than others.

The other thing that gets me confused is, on KDE, there's the option to "Allow Applications to block compositing" (see screenshot below), so Proton should be able to talk to KDE if this option is enabled and block compositing, right? image

I understand gamescope is ran via wayland and I'm not sure at all how that works, however, I do know that turning off KDE's compositing on my PC (X11, Debian 12) fixes this issue completely, so surely Proton/Gamescope/steam-runtime (i'm not too sure which application it's best suited for) should be able to do the above (please correct me if I'm wrong)?

Is there any known issues related to that here or internally? If not, how do we move forward from this as the issue doesn't seem to be unique (see this wiki link and this reddit link)?

Jaskowicz1 commented 3 weeks ago

To extend on this further (I'm aware this is closed as not planned), I cannot seem to replicate this on Steam Deck anymore (it was already hard enough to replicate on Steam Deck), so maybe this isn't an issue on Wayland.

In my honest opinion, there needs to be a fix for x11 as this is a major issue that you can find all over Google. Leaving users to manually fix this per-game isn't a good way forward for Linux gaming!

Hope we can discuss this further and find a solution as this is really irritating for many people including myself.

davidedmundson commented 3 weeks ago

Just to confirm you couldn't reproduce on Steam Deck in desktop mode?

If you can run Old School Rally in windowed mode and share the output of "xprop" and clicking in the window that would be useful. It'll show if that's requesting to inhibit compositing.

Jaskowicz1 commented 3 weeks ago

Hi @davidedmundson

Just to confirm you couldn't reproduce on Steam Deck in desktop mode?

Yeah, I can't get it to reproduce in Desktop nor Gaming mode but I'm confident I've seen it at least once on my Steam Deck in gaming mode. I'm starting to wonder if other factors (like a nvidia gpu) are making this happen.

I've posted the output of xprop on Steam Deck here.

I feel like testing on Steam Deck is making me go insane as I know I'm not the only one with this issue (backed up by people on Reddit) but it just won't occur again.

I can reliably do this on my desktop however so I can provide that tomorrow if that would help!

I do also want to note that this issue happens in Need For Speed: Most Wanted (Steam version, 2012) as well. The issue on that game, however, seems to be eased by Proton-GE but is not entirely fixed. Old School Rally does not have the same effect.

Jaskowicz1 commented 3 weeks ago

I've tested again on my PC and I can still replicate this issue incredibly frequently.

The output of xprop on my PC looks like this. To reiterate, my PC is running Debian 12 with KDE on X11. I'm also using a Nvidia GPU (3060Ti).

It's also worth noting that, the issue is resolved sometimes when you pause and resume the game, as if the display is trying to play catch-up, however the issue can come back when you pause again or when a new map loads or sometimes when you go far from the original point. If I record the issue, OBS doesn't see it, and it looks perfectly okay on my other monitors, so it's not possible to record it. Again, turning off compositor results in this being fixed.

Edit: This is MORE than just the two games I mentioned, I've tried it on BO3 and my game actually looks incredibly smooth. I tried it on Town of Salem 2, and the animations are smoother. It's an issue on maybe every game I own and I've never realised.

zzag commented 3 weeks ago

_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 0

Yeah, _NET_WM_BYPASS_COMPOSITOR is set, but it doesn't ask the compositor to inhibit compositing.

Jaskowicz1 commented 3 weeks ago

_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 0

Yeah, _NET_WM_BYPASS_COMPOSITOR is set, but it doesn't ask the compositor to inhibit compositing.

Yeah, just read up about that on freedesktop's specification.

So the best way forward would probably be to launch a PR to set that as 1, right?

zzag commented 3 weeks ago

Yeah, this might be a duplicate of https://github.com/ValveSoftware/Proton/issues/4469 though.

Jaskowicz1 commented 3 weeks ago

Yeah, this might be a duplicate of #4469 though.

Ah, yeah, it is. We should move over to that (but I'm gonna look into doing a PR anyways lol).

Thank you!