Looking through the code I notice you wait for the OS scheduler to wake on time and then begin the frame.

The problem with this model is the accuracy of the OS thread scheduler.

Blocks the execution of the current thread for at least the specified sleep_duration. This function may block for longer than sleep_duration due to scheduling or resource contention delays. The standard recommends that a steady clock is used to measure the duration. If an implementation uses a system clock instead, the wait time may also be sensitive to clock adjustments.

I would suggest we wake early using some sort of bias and then spin checking the clock until we meet the deadline.

I'm just setting up a dev environment now. :)

Checked everything according to the guide. https://github.com/ishitatsuyuki/LatencyFleX/blob/master/docs/TROUBLESHOOTING.md At the end of the log file is :

../builtin.cpp: Querying MemoryWineUnixFuncs failed c0000135
../builtin.cpp: Look for library loading errors in the log and check if liblatencyflex_layer.so is installed on your system.

latencyflex_layer.so is in /usr/lib/wine/x86_64-unix/ and /usr/lib64/wine/x86_64-unix/, and liblatencyflex_layer.so is also in /usr/lib/

Trying to enable the middleware on Apex Legends, but game doesn't seem to allow me to enable it.

What I've done, have I missed anything?

• Installed latencyflex and latencyflex-wine
• Copied nvapi.dll64 to steamapps/common/Proton - Experimental/files/lib64/wine/nvapi/
• Added dxvk.conf to steamapps/common/Apex Legends/ as described in README
• Symlinked latencyflex_layer.dll and latencyflex_wine.dll from /usr/lib/wine/x86_64-windows/ into steamapps/compatdata/1172470/pfx/drive_c/windows/system32/
• Added launch parameters PROTON_ENABLE_NVAPI=1 DXVK_NVAPI_DRIVER_VERSION=49729 DXVK_NVAPI_ALLOW_OTHER_DRIVERS=1 LFX=1 %command%

Full Log (with DXVK_NVAPI_LOG_LEVEL=info).

System: Arch Linux 5.16.10 GPU: Radeon RX590 Driver: Mesa 21.3.6

As of 6 days ago, Deep Rock Galactic supports Nvidia Reflex.

However, I enabled LatencyFlex, and once I click "continue" on the initial loading screen, the game freezes and crashes during the "initializing" splash screen while loading into the spacerig. Disabling Mangohud causes the crash to go away, but Nvidia Reflex is still greyed out in-game, despite having it working with the same launch options and same proton version as Apex, where it is working fine.

The option stayed greyed out no matter if I selected DX11 vs DX12, fullscreen vs borderlerss windows, fps cap enabled vs disabled, etc. V-sync was disabled for all testing.

I know it's not a competitive game, so reflex isn't too necessary, but still neat that another linux game has it.

The readme instructions for setting up the UE4 Hook offset say to run this command: readelf -Ws PortalWars/Binaries/Linux/PortalWars-Linux-Shipping.debug | c++filt | grep FEngineLoop::Tick

However, PortalWars-Linux-Shipping.debug does not exist for me. PortalWars-Linux-Shipping does though. When running this command on PortalWars-Linux-Shipping, it returns nothing. However, running readelf -Ws PortalWars/Binaries/Linux/PortalWars-Linux-Shipping | c++filt | grep FEngineLoop (without the ::Tick on the end) returns:

10585: 0000000000ae11c8 56 OBJECT GLOBAL DEFAULT 11 vtable for FEngineLoop.

Running readelf -Ws PortalWars/Binaries/Linux/PortalWars-Linux-Shipping | c++filt | grep Tick (without the FEngineLipp on the end) returns an extremely large amount of variables, and running it with ::Tick or ::tickalso returns nothing.

Would ae11c8 be the offset then? I'm concerned about the absence of the .debug extension in the file name, and concerned about the absence of the ::Tick() extension in the readelf... command.

Also, is there no concern over getting banned in Splitgate for using UE4 Hooking? Splitgate, even on linux, uses EQ8 anti-cheat. However, in the table of tested games in the readme, only Apex and Overwatch have anti-cheat warnings on them -- not Splitgate. Is there a reason these games have this warning, but Splitgate doesn't?

Next release of Northstar will support this. The original title never supported Nvidia Reflex, so this is a "native" implementation of LatencyFlex using the wine extensions.

While I am playing Overwatch and Apex Legends, there are times where I will be getting 100+ fps, and then the framerate will decide to drop to ~20fps and remain there until I disable Nvidia Reflex in-game.

For Apex, this only happens when I alt+tab back into the game while loading into a match (character select / champion screen). Even then, it seems inconsistent to reproduce -- so that isn't too much of an issue, as the few times it does happen, I can just quickly disable and re-enable reflex to fix it.

However with Overwatch, it usually happens multiple times per match, to where I have to disable reflex to play the game comfortably. I have noticed it pretty consistently happens whenever an enemy Sombra uses their ultimate. It is oddly inconsistent -- some matches it never happens, most matches it happens 3-5 times per game. It also usually happens the first time I load into a match. I tried moving the game off of my HDD and reinstalling on my SSD in case this was due to stutters from accessing the shader/DXVK cache, but that did not make a difference.

I saw that one of the dev branch build artifacts had a commit titled "Reduce jitter strength and pace down factor," which sounds like it could fix the issue (?), but the dev branch build artifacts are expired, so I am unable to download and test that.

Are there any other reports of this happening? If the issue can't be reproduced, let me know which logs/additional info (if any) are needed. Thanks for the amazing work by the way, it at least makes a massive difference in Apex.

The titled is true but towards the end of this post it won't be lol because I encounter a weird bug I think its specific to having the installed game on a different drive. for example on my setup before I fixed the problem by redoing the steps but having apex on the same drive.

here is how it was structured

drive: a) has apex on my mainos drive: b) accessing apex in drive a where originally I was using drive:a as my gaming but decided later to use a new os for my gaming. After finishing the new install and downloading the required packages to get steam to run apex. A biit later, I got everything all setup an running, now I just imported my steam library where in this case would be in drive:a so I choose drive:A/home/kunihiro/.local/share/Steam... and it found my apex install thats good.

Drive:A ) Main OS/
├─ Apex - installed with MainOs steam install 
Drive:B ) Gaming OS/
├─ Steam accessing Apex in Drive:A

at this point I grabbed lutris fixed up everything there along with the env vars for apex to get latencyflex running. I installed everything to the right place but a weird things I had to do was directly set the DXVK_CONFIG_FILE=/fullpathto/dxvk.conf in lutris as directly place the dxvkl.conf in the apex folder will result in a error outputted in the logs using the env var in launch options for apex PROTON_LOG=1 DXVK_NVAPI_LOG_LEVEL=info

so to solve this I had to redo every step slowly and moving my Apex to my GamingOs and setting the dxvk conf env var.

additional information:

My main os has the folder with the appid on the main os so when I start apex it starts the wine prefix in the main os where I had originally installed apex and not the second os.

so my gaming os does not create the folder steamapps/compatdata/**appid** as it is already using the one created on the main os drive:a/home/..../steamapps/compatdata/**appid**

my logs got overwritten as I keep starting Apex... sorry about that

The documentation says to include DXVK_NVAPI_DRIVER_VERSION=49729 DXVK_NVAPI_ALLOW_OTHER_DRIVERS=1 when enabling latencyflex, but this is unnecessary for people using Nvidia GPUs.

I suggest having a version for Nvidia GPUs and one for everyone else. That way the game will see the actual driver version rather than 497.29, which is out of date.

I have the following setup:

• GeForce RTX 3080
• Ryzen 7 5800X
• 64GB ECC DDR4 RAM
• Nvidia Driver 510.54
• Linux 5.16.14-gentoo-x86_64
• X11 with gsync compatibility enabled
• KDE with the kwin compositor set to prefer lower latency
• Eve Spectrum ES07D03 (144Hz 4K gsync-compatible monitor)

I am starting Apex Legends with LFX_MAX_FPS=140 PROTON_ENABLE_NVAPI=1 LFX=1 DXVK_HUD=compiler,scale=2 gamemoderun %command% -dev +fps_max=0. My dxvk.conf contains:

dxgi.nvapiHack = False
dxgi.maxFrameLatency = 1

I want to limit my FPS to 140 as per various recommendations for 144Hz gsync monitors, but when I do it via LFX_MAX_FPS in Apex Legends, my FPS often hits 144 or even rarely 145, which is outside of the gsync range and is said to disable gsync. Steam's FPS meter, Apex Legend's built-in FPS meter and DXVK's FPS meter all show FPS exceeding the value that I have set.

If I switch to DXVK_FRAME_RATE=140, then the frame rate is consistently limited to 140 FPS, but then I suspect that the DXVK limiter is causing latencyflex to misjudge how long it takes to render a frame.

I suspect that the frame rate limiter introduced in 7fed2864d5c6d4613b6aed2535e78965aa6b376f needs to be changed to do a better job of clamping the frame rate.

My launch options for Apex Legends are: PROTON_LOG=1 DXVK_NVAPI_LOG_LEVEL=info PROTON_ENABLE_NVAPI=1 LFX=1 gamemoderun %command% -novid +fps_max 180

This results in the following happening to the Steam overlay:

Once I remove LFX=1 from the launch options, this no longer happens.

Some possibly important things to note: I have Mangohud globally enabled through GOverlay. I'm playing on a 1440p, 144hz X11 session on Pop!_OS 21.10, with the Steam .deb package (not flatpak) on the latest version of Proton Experimental. I have a second 1080p monitor configured to be to the left of my main 1440p monitor. I've attached my Proton log file, which should include the DXVK_NVAPI_LOG_LEVEL=info information as well.

lfx_breaking_steam_overlay_proton.log

Let me know if I can provide any other forms of debug information, or do any kind of testing/debugging for you.

Pretty much the title.

Installation involves messing directly with the root filesystem, so it'd be nice to have detailed instructions not just for Debian and Arch. If the process is identical to one of those two, at least mentioning it would be good.

It doesn't have to be detailed for every single distro out there, but at least a couple of more common branches, like Fedora and openSUSE, would be nice.