protonscr

Optimizing the conf for latency, what are the best recommendations?

dxvkclosed question
doitsujin/dxvk#5224 · opened 2025-09-24 by matru · updated 2025-09-25 · 4 comments · github
Mmatru 2025-09-24 github

I do not care for the highest FPS, but rather lowest latency. Now the higher FPS, the lower latency also applies, but still if I can optimize towards benefiting more towards latency, rather a higher FPS outcome, I would opt for the former.

I am looking for competitive settings in StarCraft 2 on Windows.

Here is some things I've seen recommended purely from latency standpoint:

dxgi.syncInterval = 0
d3d9.presentInterval = 0
dxgi.maxFrameLatency = 1
d3d9.maxFrameLatency = 1 
dxgi.maxFrameRate = -1
d3d9.maxFrameRate = -1
dxvk.latencySleep = True

Also, in nvidia settings, this should probably be selected, then borderless/fse should work appropriately https://i.imgur.com/o8A5roZ.png

Although in https://github.com/netborg-afps/dxvk, @netborg-afps mentions:

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.

Speaking of which, @netborg-afps repo has a lot of additional settings, like:

dxvk.framePace = "low-latency"
dxvk.lowLatencyOffset
dxvk.lowLatencyAllowCpuFramesOverlap

But I am not sure why in this discussion, @doitsujin considered them redundant, though I believe there were commits that even improved upon those initial ones.

Then there is the graphic optimization part that can be configured within DXVK, like various types of texture filtering, negative LOD bias, backbuffers. Although not sure if I can let the game itself manage these.

Finally, I also responded, and it's on the topic of FPS limiting within DXVK, since frame limiters can be crucial in order to replicate what Reflex is doing, even though more so in GPU bound scenarios, but I am confused since the last statement from @doitsujin was the following:

So, if your goal is to reduce overall input latency, it won't help, whereas the in-game limiter probably does. If your goal is to improve frame time consistency, it's fine, it won't really make anything worse.

While @netborg-afps repo says:

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.

StarCraft 2 is mostly a CPU bound game, I do have the 5800X3D and that cache helps a tons, but the FPS is still pretty relatively low, since it doesn't scale well past 2-3 cores. People have tripled their FPS with DXVK on Windows.

I would really love to hear from both @doitsujin and @netborg-afps on the topic, and @Digger1955 which merged quite a few of and then some features. Maybe there are some things I've missed, so feel free to add it into the discussions.

KK0bin maintainer 2025-09-24 github

The problem (and the reason why netborgs changes aren't effective) is that frame limiting done by DXVK is not guaranteed to happen at the right time.

Reflex inserts the waiting, that's necessary to keep the frame rate under a certain value, before the game reads input data. So the time between the game reading input data and the resulting frame getting displayed is as short as possible.

Any frame limiting done without integration of the game cannot do that. DXVK has no way of knowing when the game samples inputs or how the game does multithreading. So it's possible that the game runs the simulation step for a frame and DXVK waits after that which just increases the time between reading inputs and the frame showing up on screen. That doesn't help with latency. I personally think the netborg fork is almost entirely placebo.

I believe that's what @doitsujin meant when he wrote:

So, if your goal is to reduce overall input latency, it won't help, whereas the in-game limiter probably does. If your goal is to improve frame time consistency, it's fine, it won't really make anything worse.

Nnetborg-afps 2025-09-25 github

We need that low-latency though in dxvk. Nvidia and AMD have low-latency modes in their drivers, and so should dxvk. Reflex is more geared towards d3d12 games, and rarely has an effect on d3d11/9/8 games.

@K0bin I know you think that way. Doesn't make it right. I've recently did some blind testing of a scene which had 1.5 ms render-latency with my low-latency frame pacing and which had 2.4 ms with default dxvk, both with 300 fps cap in Ultrakill (Unity Engine game, cpu bound). I scored a 100% on this blind test.

https://github.com/netborg-afps/dxvk/actions/runs/17911057103

I haven't written much in the pull request recently, because I want to first finish this project. I don't want to bother @doitsujin with iterative updates.

Mmatru 2025-09-25 github

I'll connect this to the other topic we've just discussed.

@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 latency (since b3cbe36 ) , 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.

@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?

Ddoitsujin maintainer 2025-09-25 github

If this entire thread is about netborg® snake oil™ then I'd suggest moving the discussion to their fork.

I don't know if Starcraft has a dedicated render thread, but if it does then any settings in DXVK will not do much, no matter what certain people are going to tell you. If you're entirely CPU-bound anyway then d3d9.maxFrameLatency and latency sleep won't have any effect anyway, these options (just like Reflex and friends) exist to make the app wait for the GPU to finish processing stuff to reduce latency.

Upstream links