Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Steam Deck][Latency] Noticeable input lag with frame limiter turned on #474

Open
andrebrait opened this issue Apr 25, 2022 · 23 comments
Open

Comments

@andrebrait
Copy link

I have noticed there is some input latency when the frame limiter is turned on versus when it's off or when the game is limiting FPS internally, in The Witcher 3.

I took some "measurements" by filming a button prompt reacting to me pressing the X button. I used my Samsung Galaxy S22+ which can shoot at 960fps. It's a crude measurement, but I tried the same strategy with the UFO test on my 144Hz monitor and I got an accurate result, so I think the results here are somewhat valid.

Both options were tested with V-Sync off in the game settings.
Both options were tested with a limit of 30 frames per second.
The frames were counted from the moment my finger bottoms out the X button to the first panel refresh pixels start to change in the button prompt.

  • In-game FPS limiter: 77 frames, which equal to around 80ms, or 4.8 panel refreshes at 60Hz
  • Gamescope FPS limiter: 150 frames, which equal to around 156ms, or 9.36 panel refreshes at 60Hz

While I can't get an exact figure for the delay, it seems to be around double whatever the normal delay is.
I suspect this has to do with how the strategic buffer withholding works in Gamescope.

If I understood it correctly and if we can get the time spent by the game to render the frame, it should be possible to implement a less-reliable, low-latency mode by changing how the wait is done and when the buffer is freed for the game to render the frame to. My initial thoughts are to let the user choose that, aware that a frame skip or tearing might happen if the game exceeds the target rendering time.

@Joshua-Ashton
Copy link
Collaborator

We used to have a low latency fps limiter but it was broken by xwayland doing unbounded commits. You can find it in the commit history. Once we solve xwayland blit commit nonsense we can being it back.

@andrebrait
Copy link
Author

@Joshua-Ashton and what would it take for that to be fixed? A change on upstream xwayland? Or is it something that can be done in this codebase?

@Joshua-Ashton
Copy link
Collaborator

Need to eliminate the blits or limit them the same way the app gets limited, yeah

@andrebrait
Copy link
Author

andrebrait commented Apr 26, 2022

@Joshua-Ashton just asking because I might start looking into it, but is that something that a change on gamescope would be able to deal with? Or does it depend on something else?

@andrebrait
Copy link
Author

@Joshua-Ashton are you referring to what was removed in 4ed0c26?

@TiZ-HugLife
Copy link

The input latency conversation came up on Reddit again, and MangoHud is being advertised as a potential way to limit frames with SteamOS's frame limiter turned off for reduced input latency. That is, they activate it inside the application and ask it to limit FPS rather than Gamescope. Could the frame limiter in MangoHud be of use here, or would that just result in Gamescope being frame limited without the game--the more intensive application--being frame limited?

@Jademalo
Copy link

I wrote the thread mentioned above, and can confirm that in all of my testing limiting the framerate with MangoHud provided better results than the built in limiter in the Deck (which I assume is using gamescope to limit?)

I've attempted to tinker with the instance of MangoHud that the deck runs on gamescope to see what the results would be, but haven't been successful in modifying anything.

@Mushoz
Copy link

Mushoz commented Oct 11, 2022

We used to have a low latency fps limiter but it was broken by xwayland doing unbounded commits. You can find it in the commit history. Once we solve xwayland blit commit nonsense we can being it back.

Is this an issue that needs to be solved upstream in xwayland, or would this have to be solved in Gamescope itself?

@andrebrait
Copy link
Author

The input latency conversation came up on Reddit again, and MangoHud is being advertised as a potential way to limit frames with SteamOS's frame limiter turned off for reduced input latency. That is, they activate it inside the application and ask it to limit FPS rather than Gamescope. Could the frame limiter in MangoHud be of use here, or would that just result in Gamescope being frame limited without the game--the more intensive application--being frame limited?

@Joshua-Ashton could you chime in with whether you think this should be possible or not? Or maybe if the Steam Deck should look into limiting frame rate with MangoHud instead, at least for the time being?

@etewassad
Copy link

Is this issue being worked on? I don't think Mangohud is a proper solution as it creates inconsistent frame pacing.

@bdlowery
Copy link

bdlowery commented Apr 6, 2023

Still experiencing this issue a year later.

@TiZ-HugLife
Copy link

TiZ-HugLife commented Jun 5, 2023

Hi there. So... is there any update on this situation at all? Have the required changes in xwayland or other upstream components been made? Have any workarounds been implemented here or in other downstream components?

Now that Street Fighter 6 is out, there are platform-specific input latency tests being performed, and Deck performs the worst out of all of them. It's already bad that it differs from (presumably Windows) PC, but it's worse that it's doing worse than all the consoles, including base PS4. The tester indicated that the results should be interpreted as all consoles being the same, but we know nobody is going to listen to that, and we're going to get ripped on. Heck, even I'm troubled by the results.

The tester has also not indicated whether or not this test was performed with the frame limiter disabled, but I am inclined to presume that tests are done with default settings until the tester tells me otherwise. I'm not sure someone would know to turn off the frame limiter to improve latency unless someone told you.

@fatihG
Copy link

fatihG commented Jun 6, 2023

The tester indicated that the results should be interpreted as all consoles being the same, but we know nobody is going to listen to that, and we're going to get ripped on. Heck, even I'm troubled by the results.

Tester said all current gen systems.
I dont think the SD and PS4 consoles are considered for that.

@TiZ-HugLife
Copy link

Tester said all current gen systems. I dont think the SD and PS4 consoles are considered for that.

Tester did clarify precisely that in this tweet: "By current generation I mean ps5 xss xsx and pc." So indeed, the Deck is not considered "current generation" for some reason. :/

@Shakahron
Copy link

Would appreciate an update. This is my biggest problem with my steam deck by far.

@Tau5
Copy link

Tau5 commented Sep 27, 2023

Hi, has there been updates on this?
What are the blocking issues on xwayland if you can point to them?

@DanyIsCome
Copy link

Hi, is there any update on the matter? The input lag is basically rendering unusable the fps limiter for me

@AnonPol
Copy link

AnonPol commented Nov 20, 2023

It seems this issue is reduced significantly (especially for lower frame rates) in the New Preview Firmware. @Jademalo Could you confirm MangoHUD FPS Limiter is still having better Input Lag after updating to the New Firmware?

https://youtu.be/LkrV6VlGPIE?si=nY5yfHtcsT31aEim&t=535

@Jademalo
Copy link

I haven't got the time to test unfortunately, nor do I really have the ideal means to do so. I was just doing it with an iphone slow-mo camera.

If anyone else can test that would be appreciated, though I've got a feeling the actual issue of the built in frame limiter hasn't been fixed and this is just something else that happens to improve things.

@AnonPol
Copy link

AnonPol commented Nov 26, 2023

@Joshua-Ashton Sorry to bother you but Any Updates on the Low Latency FPS Limiter? The Input Latency while improved on the New Preview Firmware is still not great.

@TiZ-HugLife
Copy link

TiZ-HugLife commented Feb 2, 2024

Nigel Woodalls did latency testing for Tekken 8 and the Deck once again got completely run over, this time to an even worse degree than with Street Fighter 6. With vsync off in-game, avg latency is 100ms, vs slightly less than 60ms on every other platform. With vsync on in-game, it drops to 90ms. This makes sense since you have to go out of your way to enable tearing, and gamescope will wait to present otherwise, whereas with vsync on, the game handles presentation timing and it happens to be in time for when gamescope wants to present.

But that's 30ms that is left unexplained. I really, truly hope that Nigel simply forgot to turn off the frame limiter, because if that's not the cause, we may have bigger problems. It's also possible that the temporal upscalers he's using as recommended by Digital Foundry impose additional latency.

There been almost two years of radio silence on this issue. Because it has gone unaddressed, I ended up making a script to make it easier to use MangoHUD's limiter for specific games instead. I would really much rather there be a fix in SteamOS itself.

The radio silence suggests that fixing xwayland's behavior may be a dead end, or at the very least, it's getting blocked. And depending on who is blocking it, it may be much more worthwhile to do frame limiting at the application layer, because then you will actually accomplish something rather than waiting for a stubborn desktop or whoever else is in your way to buckle under the pressure of an actual use case. We could integrate libstrangle, or if something is wrong with its approach, split MangoHUD's FPS limiting code out into a new library if we don't feel like pulling the entire MangoHUD layer into an application just to limit its FPS.

EDIT: Nigel has verified that he is indeed enabling tearing and turning off the limiter. This is actually really worrying, because now we don't have a clear cause to point to for the increased latency compared to other platforms. :(

@AnonPol
Copy link

AnonPol commented Feb 14, 2024

The radio silence suggests that fixing xwayland's behavior may be a dead end, or at the very least, it's getting blocked. And depending on who is blocking it, it may be much more worthwhile to do frame limiting at the application layer, because then you will actually accomplish something rather than waiting for a stubborn desktop or whoever else is in your way to buckle under the pressure of an actual use case. We could integrate libstrangle, or if something is wrong with its approach, split MangoHUD's FPS limiting code out into a new library if we don't feel like pulling the entire MangoHUD layer into an application just to limit its FPS.

EDIT: Nigel has verified that he is indeed enabling tearing and turning off the limiter. This is actually really worrying, because now we don't have a clear cause to point to for the increased latency compared to other platforms. :(

Appreciate the reply but Tekken is just 1 game. Others have reported lower input lag with Steam Deck Limiter Off than other platforms:https://www.reddit.com/r/SteamDeck/comments/ytejm0/what_does_the_allow_screen_tearing_option_do/

I dont know about libstrangle but I feel MangoHUD and DXVK are useless as Limiters as they have Frame Pacing Issues compared to Deck Limiter. I feel fine locking FPS to 45 FPS on my LCD Deck but for games which require 30 FPS Lock I feel its better to just use Powertools to lock the GPU and CPU Clocks to get Good Battery Life as Input Lag Added is Zero and while it would not give as good Frame Pacing as Deck Limiter I feel it should be equivalent to MangoHUD while having much lower latency.

@AnonPol
Copy link

AnonPol commented Feb 14, 2024

@HugLifeTiZ Note there is a bug where FPS Limiter stays Enabled even though its set to Disabled in QAM. The way to fix it is once inside the game open the QAM to enable the FPS Limiter and disable it again.

This happened to me personally 3 months ago and I am not sure its fixed now. If not that probably explains Nigel's results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests