LatencyFlex 1&2

[jarrard]

Nothing overly complecated.
Be nice to have toggles for LatencyFlex 1 and 2 (2 is being developed but does work).

For it to work there is just the need to symlink/copy the correct files to location and a couple env settings.

Would be worth having.

https://github.com/ishitatsuyuki/LatencyFleX
https://github.com/ishitatsuyuki/latencyflex2

[sonic2kk]

Sure, thanks for the suggestion!

I'm not much interested in using this myself, but it seems like it would be straightforward if it's just env settings and symlinks.

I had a quick glance at the install steps and surrounding steps (UE4 hook, Unity hook, MangoHUD integration). Most seems feasible enough except for two parts:

• The notes about UE4 and Unity hooks seem like steps that should be done manually per-game and not something that STL should handle.
• STL cannot install the Vulkan layer, this should be done manually. The steps for this vary between distros, a package to do this may be available for a given distro so STL shouldn't fiddle with it, and finally these steps require root access and STL cannot be run as root by design. This should be fine though, as I believe this Vulkan layer step only needs to be done once, and would be equivalent to "installing" latencyflex the way a user would need to install MangoHUD etc before it can be configured with STL.

There is also a note about DLL overrides for these hooks. This step and perhaps others like it which I am missing can already be configured from the STL Game Menu, so I don't think there's a need for STL to manage this explicitly either.

Currently given that latencyflex2 seems to be under heavily development, I think we should stick to implementing "latencyflex1"(?) but I will keep latencyflex2 in mind.

---

If my understanding is right, this is something that should be enabled per-game as support may not always be available or it may not always be useful. In that case it should be a toggle on the Game Menu.

On the game menu there would be a checkbox to enable latencyflex, which would export PROTON_ENABLE_NVAPI=1 DXVK_NVAPI_DRIVER_VERSION=49729 DXVK_NVAPI_ALLOW_OTHER_DRIVERS=1 LFX=1 before launch.

If this checkbox is enabled and latencyflex is not installed, the rough steps I think would be something like this:

1. Download a release of latencyflex1 from GitHub if one does not already exist or is out of date (would need to consider how to check this, maybe have a version option like we have for ReShade - Could also be a global menu option).
2. Extract this to some internal STL folder
3. Symlink latencyflex_layer.so, latencyflex_layer.dll, latencyflex_wine.dll to the current Proton version's lib64 folder.
4. Symlink these files to the current game's prefix as well at drive_c/windows/system32/. The documentation incorrectly lists the prefix folder as ~/.local/share/Steam/steamapps/compatdata - This is only for games installed on the boot drive library folder, but STL can find the prefix. On Steam Deck sometimes the prefixes are incorrectly created at this folder even for games on a microSD or external drive, but I don't think anyone would use this on a Steam Deck so it probably doesn't matter
5. Install dxvk-nvapi (Winetricks should be able to do this)
6. Create a custom dxvk.conf for the current game (STL already has frontend and backend support for doing this) to set dxgi.nvapiHack = False
7. Probably have a checkbox for to set dxgi.customVendorId = 10de when using a non-Nvidia GPU (not sure what it would be named yet though)
8. Profit!

Please correct me if any steps here are wrong. If this is about right, this will serve as a baseline for implementation :-)

Uninstallation should be trivial here for the most part as well since we're using symlinks and we know the DLL names, but I am not sure if it's overly necessary. If the environment variables aren't exported, that should be good enough I think.

---

Latency is not something I am really interested in, and I am also not overly fond of installing some Vulkan layer just to test this, so it will be up to the community to test to ensure the implementation works, come the time. Most of the steps here seem straightforward enough.

There is no ETA on when I will get around to this, so if you or anyone else in the meantime would like to work on this please feel free 🙂

[SentaiBrad]

The idea over Latency Reduction, at least when it comes to Nvidia Reflex (that was called out on Latency Flex 1) is that things like DLSS3 introduce a level of latency in its Frame Generation, and things like Nvidia Reflex can go back in, to help reduce it to a more normal level.

[sonic2kk]

No response on whether the implementation is correct so I guess I will just try and hope for the best. I won't be able to test this more than "does the game still work".

One "problem" I didn't foresee is that this will actually install the LatencyFlex version for the given Proton version and it will always be there even if you're playing a game with it disabled. Maybe the symlinking into the Proton directories should be done on-the-fly when the option is enabled.

[SentaiBrad]

I don't know of a game off the top of my head where I would want this for me on my Steam Deck, so I wouldn't even really know how to go about testing it, but I didn't even know it made it in. Global activation does sound like an issue though.

[sonic2kk]

It's not implemented yet, was just thinking out loud.

Also, Steam Deck is a secondary use case for STL. It is primarily a Linux desktop tool :-) Steam Deck support is primarily intended for Linux desktop users who also own a Steam Deck and want to use STL on it. SteamTinkerLaunch will always be experienced Linux Desktop users first.

[SentaiBrad]

Totally fair, but STL's recent popularity boom is more or less Steam Deck's "fault". :P

In terms of testing, the biggest boon for Flex is just getting that latency down. Is there a title that Proton add's great amount of latency to? DLSS2 and FSR2 don't add too much, if any, latency to games. Reflex from Nvidia has existed alongside DLSSS 1 and 2, but it became a bigger deal with DLSS3 Frame Generation which added latency. So reflex lowered the latency back to normal or better than normal. FSR3, supposedly, will have its own version of Frame Generation, and that will be a potential boon for PC Handheld gaming, and if it add's a massive amount of latency then the hardware-agnostic version of Reflex will be a bigger deal than it is now.

Reflex is also touted as great for multiplayer gaming, but that's already a crap shoot on Linux, with any layer, and Anti-Cheats, so. Less of a reason in that arena unless Anti-Cheat issues start getting solved on Linux.

[sonic2kk]

I refuse to play games that use any kind of malware anti-cheat such as EAC, so I cannot test those.

The rest of the points you make are valid indeed, and I also don't really buy into latency being an actual problem (it seems to me like marking BS, such as >60Hz displays), but LatencyFlex is still a tool that exists and I have no issue adding it to STL for users who want to use it.

It will be work, and it's still open to anyone from the community that wants to work on it because imo it fits the scope of the project even if I don't personally think it's useful. It seems mostly about creating symlinks and cleaning those up, and it seems users are using this LatencyFlex tool anyway, so adding it to STL should be fine. I would actually prefer that someone from the community work on it, because someone who is motivated and wants to use this feature would be in a much better position to implement it than me.

and that will be a potential boon for PC Handheld gaming

This is not about Steam Deck. STL features are added for Linux Desktop users first. If it's useless to Steam Deck users, that's not a reason to discredit this feature. On that point:

Totally fair, but STL's recent popularity boom is more or less Steam Deck's "fault". :P

Maybe, but to put it bluntly, I really don't care 😛 Steam Deck users have been a big factor in de-motivating me from working on STL as they tend to be Windows users that just happen to own a Steam Deck, and not technical Linux users. Most don't even use Linux full-time! They are the exact opposite audience that STL is aimed at, which is for technical users which want to tinker. STL gives them one avenue to help them tinker. Given the nature of the Steam Deck it is a little more challenging to tinker, but that isn't up to STL to solve.

This also somewhat demotivated the previous maintainer, and I can see why.

I'm not obligated to give Steam Deck users any priority just because it seems to have given STL "popularity". I won't avoid adding a feature just because it may not be useful on Steam Deck. STL is Linux Desktop first, and some features may also be useful on Steam Deck. STL was around long before the Steam Deck and will continue to exist even if every Steam Deck user stopped using it.

I am not here to make a tool for Steam Deck users. I am here to make a tool for more technical Linux Desktop users who want to get their hands dirty with some tinkering. SteamTinkerLaunch is a Linux tool, not a Steam Deck tool. It just so happens the Steam Deck runs Linux and so there is overlap, and I do make a point of fixing issues where I can on Steam Deck, but I won't shoehorn in features just for Steam Deck users, or avoid adding features if they can't be used on Steam Deck.

I should also point out that there is plenty of missing functionality on Steam Deck, and probably more that is not very useful on Steam Deck compared to Linux desktop (such as Nyrna, even if it worked).

[SentaiBrad]

To be fair, a lot of that list has been solved (though, probably not to the degree STL needs it to be at) or is in the process of being solved, but I didn't know that Steam Deck was negative for STL. I can see why, but it's also bringing in money which is making things move forward to an extent they weren't before.

So, both sides of the argument (of which I have none to be fair) have pros and cons. I just like tools that make what I want to do easier or better, like STL.

I'm not a Linux user main-stay, but I'm also not the set it up and forget it Windows person. I make things work the way I want them, and that's part of why I love my Deck. Either way, makes sense and I get why it's not a fun topic.

As for the topic of LatencyFlex: I haven't seen a need myself for reducing latency, but I'm not using DLSS3 Frame Generation or playing multiplayer games. I've not confirmed myself if DLSS3 works the way it should on Linux, FSR3 is some time off, and the multi-player games that would be best targeted are not fully operational on Linux as a whole. Games like Apex Legends, Halo, etc.

I do personally use a 140hz monitor, and work hard at making sure my frame times are as low as they can be on PC and Deck, but LatencyFlex or Nvidia Reflex are not going to help that in that area.

[jarrard]

If frame-generation or fsr3 ever comes to Linux, you will probably want latencyflex 1/2 unless NVIDIA find a way to introduce NVFlex directly in the driver themselves.

Atm in normal gaming, sure latency is not a huge issue, but once you start diddling with frames like DLSS-FG does, reducing it becomes much more important and noticeable.
(These things have been extensively tested and aren't just marking BS; the 240++++++ HZ monitors however are BS)

I don't know of a game off the top of my head where I would want this for me on my Steam Deck, so I wouldn't even really know how to go about testing it, but I didn't even know it made it in.

Loads of people experience input lag (screen image being behind control input) in first person shooters mostly. Especially the online variety.

It is a big issue for some, like everyone here I don't play too many of those but I do play Witcher3 and CP2077 sometimes, and will be playing stalker-2 where latency can rear its ugly head.

Sometimes we must be a little humble and understand not everyone plays the games we play, and some games do experience this mythical latency monster.

[sonic2kk]

To be fair, a lot of that list has been solved (though, probably not to the degree STL needs it to be at)

No, there are no plans for most of that list as they need to be installed by disabling the readonly root filesystem. For example, using Nyrna with STL has no support on the Steam Deck because it requires installing the Nyrna package. There are also no plans to include VR support for the Steam Deck from Valve. System-wide Wine support is also unsupported on Steam Deck and therefore STL.

but I didn't know that Steam Deck was negative for STL. I can see why, but it's also bringing in money which is making things move forward to an extent they weren't before.

I don't make any money off of STL (and never intend to). This is a hobby project. The Steam Deck hasn't brought in any money for STL or made things move faster. I don't use STL on my Steam Deck either for the most part, the main use-case I have is for installing VN patches and using custom executables.

---

Sometimes we must be a little humble and understand not everyone plays the games we play

Agreed, and they don't play them in the same ways. I also own a 165hz display, and have used things like 120hz and 144hz displays, and I don't see nor feel any difference from 60hz. That doesn't mean I won't add LatencyFlex though. If it was going to be a huge unreliable effort to get working I might reconsider but it seems like reasonably well defined manual steps. And this is a Linux tool. So it's different from adding some unfriendly upstream program.

I am in favour of adding LatencyFlex configuration to STL, but there is no real ETA (I'm working on other projects atm). It might be a little tricky to figure out an implementation I'm happy with mainly around downloading various versions but I think it'll be doable. I'm thinking that there'll be one global version as I'm not sure there's any benefit in per-game versions (i.e. one game using 1.1.0 and another using, say, 0.9.2). Do correct me if I'm wrong.

STL will then just download the newest version if LatencyFlex is enabled and remove the old version, hopefully the install process won't change much especially considering LatencyFlex2 is in development.

[SentaiBrad]

Regardless of how anything shakes out, I do appreciate these threads being open, honest, and with no judgment or normal internet bullshit. I appreciate folks just being human and wanting to share what they love. That's why I took to STL on my Deck because I love to do stupid stuff because I can. xD

Thank you to Sonic and any other maintainers.