Thanks so much for your response. This really clears things up for me!

Just wanted to say I found this thread because even though I was getting 200+ fps, things were still visually off. I set DXVK_FRAME_RATE to 150 (monitor max is 144), and turned vsync off in game (on helped slightly but still wasn't perfect) and now things are buttery smooth! Thanks!

Just wanted to say I found this thread because even though I was getting 200+ fps, things were still visually off. I set DXVK_FRAME_RATE to 150 (monitor max is 144), and turned vsync off in game (on helped slightly but still wasn't perfect) and now things are buttery smooth! Thanks!

Super late, I know, but If your monitor is 144hz it definitely has freesync support and you should cap your framerate at 140fps, not 150fps. Otherwise you are literally not using freesync at all since you are completely out of the range, and you are introducing screen tearing for no good reason.

Super late, I know

Yeah I cap at 140 now, have for a long while.

It's an old thread and people moved on with their lifes probably :) so excuse me.
But I wanted to point out, something has changed between dxvk version 2.6.2 and 2.7-25-gc3125fe454c3f29 for the better!.
To prevent any possible wayland shenanigans, i tested in x11 openbox without any compositors.

When fps is capped at 60, with the newer version of dxvk there is 0 input lag.

Note: I dont have a high precision camera or anything, i tested with an older version world of warcraft where hardware cursor option is set, so cursor rendering has no delay, and with an addon called _Cursor a model is rendered at the cursor position. So if the cursor is moving but the model is lagging behind there is an input delay. With the newer version of dxvk they are perfectly synced when fps is capped. Some genius work has been done, thanks!

I hope we will see the same with vkd3d.

Edit:
On hyprland (wayland) even with "allow_tearing=true" (i can see screen tears) there is input delay.
On kde-plasma (wayland) "Screen Tearing" doesn't work on my nvidia gpu.
So long live x11.

It's an old thread and people moved on with their lifes probably :) so excuse me.
But I wanted to point out, something has changed between dxvk version 2.6.2 and 2.7-25-gc3125fe454c3f29 for the better!.
To prevent any possible wayland shenanigans, i tested in x11 openbox without any compositors.

When fps is capped at 60, with the newer version of dxvk there is 0 input lag.

Note: I dont have a high precision camera or anything, i tested with an older version world of warcraft where hardware cursor option is set, so cursor rendering has no delay, and with an addon called _Cursor a model is rendered at the cursor position. So if the cursor is moving but the model is lagging behind there is an input delay. With the newer version of dxvk they are perfectly synced when fps is capped. Some genius work has been done, thanks!

I hope we will see the same with vkd3d.

Edit:
On hyprland (wayland) even with "allow_tearing=true" (i can see screen tears) there is input delay.
On kde-plasma (wayland) "Screen Tearing" doesn't work on my nvidia gpu.
So long live x11.

@doitsujin Could you confirm this change? What actually changed that dxvk frame limiter no longer adds input latency?

It was also recommended here: https://github.com/netborg-afps/dxvk by @netborg-afps:

Fps limiting is also useful in other modes to improve consistency and/or to save power. Limiting in the low-latency modes is tightly integrated into the frame pacing and is strongly recommended to be used in place of most ingame limiters.

@matru I gave that recommendation because I've seen "high-latency" limiters in games such as Overwatch 2 which can easily be bettered within a Direct3d solution. Possibly these games are trying to get smooth results, but from an application level they don't have enough control to also account for best latency. There are other games like Apex which have a great built-in limiter, which wouldn't be improved within dxvk.

The default dxvk fps limiter is good and smooth and generally doesn't add much latency (since https://github.com/doitsujin/dxvk/commit/b3cbe36c08b830963e09752763df66dc3d281cd3 ) , but in my low-latency pacing there are two other kinds of limiters active to fine-tune it a bit more towards low-latency. One which limits at the start of the frame, and one which predictively avoids going into v-sync buffering for the VRR mode.

I'll reiterate the question here since I am interested in the reason behind the following:

@netborg-afps Why not use the nvidia driver limiter or even RTSS (which works the same as Nvidia limiter in Nvidia Reflex mode, but also has the older Async mode)?

I believe SC2 has a very bad implementation for an in-game limiter, but Nvidia Driver limiter nowadays should add at most 1 frame, or 0 in proper scenarios. Why care about the dxvk framelimiter? I know that dxvk.latencySleep = True won't be effective if you don't use dxvk implementation for limiting, but if you do use the Nvidia limiter + cap your GPU to 90-95% utilization through FPS, or even unlimited in certain scenarios where games don't ever utilize the GPU, then isn't that doing whatever within dxvk optimizations are?

@matru I play on linux and the only other possible limiter in question there would be Mangohud, which would be similar to RTSS. External Vulkan-based limiters however add 1 frame of latency because they do stall within vkQueuePresentKHR, which is decoupled from the d3d frame logic. The dxvk framerate limiter works similar to a d3d11 driver fps limiter and can feature low latency for most games.

I haven't tried SC2 specifically, but I'm pretty sure d3d frame pacing will work out pretty well there. For whatever reason the dxvk maintainers are still not interested in this topic and try to argue games would need to implement pacing via external solutions like Reflex, which is not feasible for older games and secondly isn't even necessary if games just follow the principle of sampling input after calling d3d present() which most games do (for d3d12 maybe not, but that would be due to the low-level API not providing a strict frame boundary - maybe it would even work there, I haven't looked into it deeply).

cap your GPU to 90-95% utilization through FPS

Well, fps limiting works frame by frame. In case of capping it to 95%, there are probably still frames going into GPU buffering. I probably would need to fire up SC2 to see how dxvk handles that. In some cases dxvk creates latency not related to GPU usage at all.

@netborg-afps Thanks. I didn't know this, on Linux the Nvidia Frame limiter is not available at all?

Under Does the RTSS FPS limiter really “add” 1 frame of input lag? on blurbusters. You can read this:

However, with an FPS limit (RTSS or in-game), so long as the framerate can be sustained above the set limit, a constant framerate/frametime target is now ensured, and the pre-rendered frames queue effectively becomes “0,” until at any point the framerate falls below the set limit, where the queue once again takes effect.

Thus, a framerate limited by RTSS can actually have 1 frame less input lag than the same uncapped framerate does with “Maximum pre-rendered frames” at “1.”

So in theory, if properly setup, this 1 frame latency won't happen. And the 90-95% utilization helps with that too. And you don't even need Reflex to achieve this, it's harder to setup since you need to benchmark it.

I am not understanding this one:

External Vulkan-based limiters however add 1 frame of latency because they do stall within vkQueuePresentKHR, which is decoupled from the d3d frame logic. The dxvk framerate limiter works similar to a d3d11 driver fps limiter and can feature low latency for most games.

Won't Nvidia limiter negate this effect on Windows?

There is no Nvidia fps limiter on Linux.
If RTSS adds 1 frame of input lag will depend on how it injects itself when dxvk is running, I would be able to test this with my monitor's built-in Nvidia Reflex Analyzer. Afaik it detects the game running on Vulkan. So if it tries to framerate limit within the Vulkan domain, it will create one frame of latency. Same goes for Nvidia's fps limiter on Windows which will see a game running with dxvk as Vulkan application.

So if it tries to framerate limit within the Vulkan domain, it will create one frame of latency.

but only if it cannot sustain the frame rate below the set limit as I said:

However, with an FPS limit (RTSS or in-game), so long as the framerate can be sustained above the set limit, a constant framerate/frametime target is now ensured, and the pre-rendered frames queue effectively becomes “0,” until at any point the framerate falls below the set limit, where the queue once again takes effect.

Also in games like SC2, where you can achieve 200-300 FPS with DXVK, this 1 frame of input lag becomes much more minuscule if it does happen.

However, with an FPS limit (RTSS or in-game), so long as the framerate can be sustained above the set limit, a constant framerate/frametime target is now ensured, and the pre-rendered frames queue effectively becomes “0,” until at any point the framerate falls below the set limit, where the queue once again takes effect.

this only applies to RTSS fps limiting in the d3d domain. As written, it's impossible to not create one frame of latency if you fps limit dxvk externally within the Vulkan domain.

Also in games like SC2, where you can achieve 200-300 FPS with DXVK, this 1 frame of input lag becomes much more minuscule if it does happen.

Well this is subjective preference.

Greetings, @matru.

If you are going to use dxvk low-latency or my DXVK-GPLALL here are the dxvk.conf settings that will get you the lowest latency in StarCraft 2 D3D9 x64 on Windows:

# d3d9.presentInterval = 0 # Not necessary, if VSync turned off in driver and application.
d3d9.maxFrameRate = x # x - Desired frame rate, depends on PC configuration. Recommendation - to get the smoothest result with quickest input response and lowest variance in any situation set the FPS value, which you can achieve in the most CPU-bound scene.
dxvk.latencySleep = False # Condition for dxvk.framePace = "low-latency"
dxvk.framePace = "low-latency"
dxvk.lowLatencyOffset = 0 # For the specified use-case, it is better to set dxvk.lowLatencyOffset = 0, since positive values may lead to more stress for the already stressed CPU and negative values will lead to slower input response.
dxvk.lowLatencyAllowCpuFramesOverlap = False # If d3d9.maxFrameRate was properly calculated, setting dxvk.lowLatencyAllowCpuFramesOverlap = False will lead to quicker input response.

@K0bin and @doitsujin

netborgs changes aren't effective

I personally think the netborg fork is almost entirely placebo.

netborg® snake oil™

Note: I am simply reporting results that I observed on my configuration.

1. DXVK common implementation of lower latency mode a.k.a. dxvk.latencySleep = True is ineffective in most applications and have no effect when used with any kind of FPS Limiters, as it is stated in dxvk.conf setting note.
   @netborg-afps dxvk.framePace = "low-latency" mode is effective in all applications that I have tested - Link to list of tested applications on DXVK-GPLALL Wiki - and it is effective when used with FPS Limiters.

2. DXVK work to make proprietary NVIDIA Reflex available is useless for my configuration, because I do not have NVIDIA GPU.
   @netborg-afps work to make global universal (GPU vendor-independent) low latency mode is useful for variety of configurations and mine in particular.

@netborg-afps I hope that you will continue your work, thanks for it.

@Digger1955 Thanks for the input, however I could not find latency comparison tests between core vs the forks in the provided link?

Also I've found this on your wiki, but I you didn't specifically recommend these since most of them are for GPU bound scenarios?

@matru, low-latency part of DXVK-GPLALL is identical to the original @netborg-afps dxvk low-latency, no changes were made. Differences may be observed only because of DXVK-GPLALL changes to compilation settings, added "Async" feature and/or disabled by default GPL (Graphics Pipeline Library) support.

Also I've found this on your wiki, but I you didn't specifically recommend these since most of them are for GPU bound scenarios?

Yes, Performance Tweaks may increase GPU-bound performance, but they probably will not help in StarCraft 2, because StarCraft 2 is mostly CPU-bound.
Here is additional info with benchmarks about StarCraft 2 Graphics Settings - https://old.reddit.com/r/allthingszerg/comments/m9v58e/graphic_settings_recommendations_in_starcraft_2/ - I used this info to configure StarCraft 2 (when I played it long time ago), so it would not stress my GPU, but it helped both GPU and CPU.

Here is additional info with benchmarks about StarCraft 2 Graphics Settings - https://old.reddit.com/r/allthingszerg/comments/m9v58e/graphic_settings_recommendations_in_starcraft_2/ - I used this info to configure StarCraft 2 (when I played it long time ago), so it would not stress my GPU, but it helped both GPU and CPU.

Thanks @Digger1955, I'll be probably using https://tl.net/forum/starcraft-2/498454-hybrid-settings-30-lotv-edition, the medium settings one, there is a need of changing a few variables in variables.txt, that won't be an issue when used with dxvk?

@matru, I saw them too, but I did not use them, because these settings were written for older StarCraft 2 version and some users reported that they had problems when using these settings, like graphical bugs or crashes on startup.

there is a need of changing a few variables in variables.txt, that won't be an issue when used with dxvk?

I do not know. I do not have installed StarCraft 2 now to check it. Don't forget to backup variables.txt before making any changes.

@Digger1955 there are reports it still works fine, since Lotv is the latest expansion, I'll dabble into it more, maybe report back.

By the way, if using dxvk limiters, do you recommend setting the latencyTolerance to 0 for better latency? What about disableNvLowLatency2?

Also, since SC2 is only utilizing 1-3 cores at best with dx9, are there ways I can improve this with dxvk, or it happens by default when using it?

Finally, what's your opinion on https://www.pcgamingwiki.com/wiki/Nvidia_Profile_Inspector#Layer_Vulkan.2FOpenGL_on_DXGI_swapchain or dxvk.allowFse = True?

I am unsure if the former is superior now in 2025, since the previous recommendation were:

On Windows, the dxvk presentation is not optimal since support for the dxgi flip model is not implemented yet. It's strongly recommended to set dxvk.allowFse = True on Windows to enable the old fullscreen exclusive mode.

But the the settings that I've just linked with the DXGI swapchain, might point otherwise.

@matru, I'll try to answer your questions:

By the way, if using dxvk limiters, do you recommend setting the latencyTolerance to 0 for better latency?

As specified in DXVK-GPLALL Wiki:

For the best frame pacing, it is recommended to align values of dxvk.latencyTolerance and dxvk.lowLatencyOffset. If dxvk.lowLatencyOffset = 0, then dxvk.latencyTolerance = 0.

Since DXVK default value is dxvk.latencyTolerance = 1000, setting dxvk.latencyTolerance = 0 will lead to lower latency as well.

What about disableNvLowLatency2?

As specified in DXVK-GPLALL Wiki:

VK_NV_low_latency2 extension only available on NVIDIA GPUs and is not used, if dxvk.latencySleep = False, which is default for this build.

If you set dxvk.latencySleep = False, NVIDIA Reflex gets disabled too - DXVK-GPLALL Wiki.

Also, since SC2 is only utilizing 1-3 cores at best with dx9, are there ways I can improve this with dxvk, or it happens by default when using it?

It happens by default, no user actions required.

Finally, what's your opinion on https://www.pcgamingwiki.com/wiki/Nvidia_Profile_Inspector#Layer_Vulkan.2FOpenGL_on_DXGI_swapchain

I do not have NVIDIA GPU, but as specified here this setting is required for DXVK to work at all on NVIDIA GPUs in some cases. From info provided here, I would assume that it will be beneficial in your case.

dxvk.allowFse = True?

As specified in DXVK-GPLALL Wiki:

Recommended value: dxvk.allowFse = False
On Windows 10/11, if you are not using HDR or Variable Refresh Rate (VRR) or application specifically does not require Fullscreen mode - it is recommended to leave it at default value, because in new Windows versions WDDM and DWM are optimised for Fullscreen Borderless and Windowed modes, but not for Exclusive Fullscreen mode.
Also, the Exclusive Fullscreen mode can be dangerous on application's first launch, because, if application on its first launch fails to properly autodetect your display parameters (happens all the time to old D3D8/D3D9 games and even some newer D3D11 games) - this can lead to GPU driver crash in some cases.
It is recommended to check the effect of dxvk.allowFse = True after configuring the application's display settings.

I have answered similar question in DXVK-GPLALL issue - Link.
In your use-case, if you are going to use Prefer layered on DXGI Swapchain, dxvk.allowFse = False is better choice to achieve both lower latency and smooth frame pacing.

@Digger1955 Thanks so much for this detailed input! I really appreciate it.

For the best frame pacing, it is recommended to align values of dxvk.latencyTolerance and dxvk.lowLatencyOffset.

But in the case of core dxvk, lowLatencyOffset is not supported, to get the best latency would it matter to set latencyTolerance to 0 at all times, also even if not using the patches?

If you set dxvk.latencySleep = False, NVIDIA Reflex gets disabled too - DXVK-GPLALL Wiki.

but disableNvLowLatency2 should work if latencySleep is set to True, so in which cases should I use disableNvLowLatency2 if I already limit the frames through dxvk limiter and use latencySleep = True?

In your use-case, if you are going to use Prefer layered on DXGI Swapchain, dxvk.allowFse = False is better choice to achieve both lower latency and smooth frame pacing.

Wow, this is very informative. Yes, I think with the new DXGI swapchain, including the additional option in NVPI, it only makes sense to use dxvk.allowFse = False. @netborg-afps Since your opinion here differs and recommend the value to be set to True, could you chime in?

@matru Well, I based this opinion on testing one particular game on Windows 10, so this is a bit narrow. But dxvk.allowFse = True gave much more fps. I don't know if this is different in Windows 11, but dxvk.allowFse = False will blit the image for presentation, which means it's copying the image. dxvk.allowFse = True however is simply switching/flipping two images (front- and backbuffer), so this is much more efficient. But then again, I don't know if certain settings, the driver, the OS might be able to override this behavior.

@netborg-afps have you ever checked allowFse True or False with: https://www.pcgamingwiki.com/wiki/Nvidia_Profile_Inspector#Layer_Vulkan.2FOpenGL_on_DXGI_swapchain

At least the first 4 options if you don't have NVPI, but that's not guaranteed to work.

@matru, answers to follow-up questions:

But in the case of core dxvk, lowLatencyOffset is not supported, to get the best latency would it matter to set latencyTolerance to 0 at all times, also even if not using the patches?

Upstream DXVK latency reduction method is different, that's why it needs to be tested. I did not conduct such tests, so I can't tell.

but disableNvLowLatency2 should work if latencySleep is set to True, so in which cases should I use disableNvLowLatency2 if I already limit the frames through dxvk limiter and use latencySleep = True?

As specified in DXVK-GPLALL Wiki (which used info from upstream dxvk.conf):

dxvk.latencySleep
Controls latency sleep and Nvidia Reflex support.
True: Enables built-in latency reduction based on internal timings. ...this will not have any effect in games with built-in frame rate limiters, or if an external limiter (such as MangoHud) is used. In some games, enabling this may reduce performance or lead to less consistent frame pacing. The implementation will either use VK_NV_low_latency2 if supported by the driver, or a custom algorithm.

If you want to limit FPS in any way - you need to use dxvk low-latency or DXVK-GPLALL with dxvk.framePace = "low-latency" for latency reduction to work.
If you limit FPS on upstream DXVK in any way - its latency reduction will not work.

dxvk.allowFse

@matru, to get the best ideal settings, you should check difference between dxvk.allowFse = True and dxvk.allowFse = False on your specific configuration, on your specific application. And if you are changing any setting/variable that may change behaviour of dxvk.allowFse - you should redo the tests again. There is no (and won't be) universally performant recommendation for this setting - only universal (mostly) compatibility (i.e. application will work somehow) can be guaranteed.

have you ever checked allowFse True or False with: https://www.pcgamingwiki.com/wiki/Nvidia_Profile_Inspector#Layer_Vulkan.2FOpenGL_on_DXGI_swapchain

@matru yes, I've checked this, but it didn't make any difference

@Digger1955 Thanks.

If you limit FPS on upstream DXVK in any way - its latency reduction will not work.

From the core dxvk.conf:

Similarly, this will not have any effect in games with built-in frame rate limiters, or if an external limiter (such as MangoHud) is used. In some games, enabling this may reduce performance or lead to less consistent frame pacing.

So it should work with dxgi.maxFrameRate = 0 and d3d9.maxFrameRate = 0

@netborg-afps This is without NVPI though?

Also, I know @Digger1955 is on Liunx, but what is your latency testing methodology @netborg-afps? And have you used something like capframeX (fork of presentmon) for testing on Windows?

This is without NVPI though?

@matru Yes, I didn't use NVPI back then as I didn't know it was a thing.
Afaik upstream dxvk made dxvk.allowFse = False default to increase compatibility and to prevent certain issues, not because of performance. This then uses the DXGI swapchain, but not via flipping, and as said, I'm not aware if this can be enforced by other means.

@matru

So it should work with dxgi.maxFrameRate = 0 and d3d9.maxFrameRate = 0

Yes, if you aren't using any other FPS limiters.

Also, I know @Digger1955 is on Liunx

No, I am not, at least for now - I am using Windows 10 21H1. And all my tests are conducted on Windows 10 21H1, Multi-Plane Overlay (MPO) turned off, dxvk.allowFse = False (upstream DXVK default).

but what is your latency testing methodology and have you used something like capframeX (fork of presentmon) for testing on Windows?

I use both my monitor's Nvidia Reflex Analyzer and log/plot latency measurements within dxvk. I've also checked presentmon, but for the most part there is no need for it, other than to confirm the present mode, where I've seen that Doom Eternal can indeed use the optimal Windows present mode with Vulkan.

No, I am not, at least for now - I am using Windows 10 21H1

@Digger1955 Oh sorry, I must've confused you with another poster.

@netborg-afps Thanks! I do recommend checking capframeX, has much more features and it's has amazing stat tracking and measuring input lag, and many other features.

@netborg-afps

Afaik upstream dxvk made dxvk.allowFse = False default to increase compatibility and to prevent certain issues, not because of performance. This then uses the DXGI swapchain, but not via flipping, and as said, I'm not aware if this can be enforced by other means.

@Digger1955

to get the best ideal settings, you should check difference between dxvk.allowFse = True and dxvk.allowFse = False on your specific configuration, on your specific application. And if you are changing any setting/variable that may change behaviour of dxvk.allowFse - you should redo the tests again. There is no (and won't be) universally performant recommendation for this setting - only universal (mostly) compatibility (i.e. application will work somehow) can be guaranteed.

Just to be clear, in general the previously linked setting: https://www.pcgamingwiki.com/wiki/Nvidia_Profile_Inspector#Layer_Vulkan.2FOpenGL_on_DXGI_swapchain

Should not matter as of today, regardless if I use allowFse or not, they use a different way of implementing this that won't matter what my NVCP options is set to (and in NVPI if I choose to do the extra mile), the best config in regards to allowFse doesn't depend on that setting?

@matru

Just to be clear, in general the previously linked setting: https://www.pcgamingwiki.com/wiki/Nvidia_Profile_Inspector#Layer_Vulkan.2FOpenGL_on_DXGI_swapchain
Should not matter as of today, regardless if I use allowFse or not, they use a different way of implementing this that won't matter what my NVCP options is set to (and in NVPI if I choose to do the extra mile), the best config in regards to allowFse doesn't depend on that setting?

Short answer: No, it matters, because any DXVK output (D3D8/D3D9/D3D10/D3D11) will be presented using DXGI swapchain.

Detailed answer (too big to copy here, with images): https://wiki.special-k.info/en/Presentation_Model

https://wiki.special-k.info/en/Presentation_Model

Great link.

@matru Just check presentmon which present mode is used when you are testing settings. Last time I checked this on Windows 10, "Hardware: legacy flip" was used for dxvk.allowFse = True and "Composed: Copy with GPU/CPU GDI" was used for dxvk.allowFse = False

@Digger1955 @netborg-afps I've also checked this: https://wiki.special-k.info/en/SwapChain, it does get complicated indeed, and beyond my pay grade on first glance apparently.

Basically I can't even know which proper combination will lead me to a given presentation model when using DXVK, it could be with allowFse True or False, borderless in the game settings or maybe not, the NVCP setting should always be on though, and if not, since it doesn't use the DXGI swapchain, what type of presentation mode would it use without that option?

Is there any preferred presentation mode that I should be aiming for, or the latency/fps benefits are mostly game to game based and option to option based as I said, so only benchmarks in a given game can provide me with the correct choice.

@matru You should aim for one of the "Hardware flip" modes for best fps and latency, which is why I recommended dxvk.allowFse = True. Unfortunately "Hardware: legacy flip" has bad alt-tab behavior and maybe has other side effects, but this was the best mode I could get within the limited time I've tested this.

As written previously, "Hardware: Independent Flip" is the most optimal mode, but I don't know if there is a way to get it without implementing support for it into dxvk.

@matru,

only benchmarks in a given game can provide me with the correct choice