Special K can drastically reduce latency

[EeK]

My base tear-free G-SYNC recommendations remain the same.

The framerate limiting selection (regardless of any SpecialK FPS limiter findings) will remain a mix of individual user preferences and goals on a per-game basis.

I'm still a little confused about Special K's "SwapChain Management" settings, when used in conjunction with its framerate limiter, and how they should be configured for G-Sync-compatible displays. We should cap the FPS at -3 below the max refresh rate and define a backbuffer?

Kaldaien suggests a backbuffer count of 4, and a maximum device latency of 5 (which he says should always be backbuffer count + 1). He also suggests enabling "Waitable SwapChain", when using flip model presentation ("Enable DWM tearing" is selected by default). The thing is, he chooses not to use G-Sync, so I'm not sure how exactly those settings relate to VRR.

There's also a "low latency mode" in Special K (under the frame limiter tab) that I don't know how is related to Nvidia's own low latency mode (which I globally set to "On" = max pre-rendered frame of 1, per your and Chris' suggestions). Not to mention those sleepless threads options - no idea what they do.

Just trying to find the most optimal settings for SK, when combined with G-Sync, as I already have NVCP and RTSS down, thanks to your guides.

[jorimt]

I'm still a little confused about Special K's "SwapChain Management" settings, when used in conjunction with its framerate limiter, and how they should be configured for G-Sync-compatible displays. We should cap the FPS at -3 below the max refresh rate and define a backbuffer?

Where Special K settings are concerned, I don't know; I have yet to test them.

From what I've gathered in this thread and elsewhere though, is his low lag limiter claims have primarily been targeted at borderless/windowed mode. I'm honestly not sure if he's even directly prioritizing exclusive fullscreen or G-SYNC where his limiter is concerned.

He'd have to chime in here to clarify.

[EeK]

Where Special K settings are concerned, I don't know; I have yet to test them.

From what I've gathered in this thread and elsewhere though, is his low lag limiter claims have primarily been targeted at borderless/windowed mode. I'm honestly not sure if he's even directly prioritizing exclusive fullscreen or G-SYNC where his limiter is concerned.

He'd have to chime in here to clarify.

Oh, it's definitely targeted at borderless windowed. As I understand it, forcing flip model presentation is made to work in a similar way as to what Microsoft tried to achieve, but ultimately failed to do so, with fullscreen optimizations - a mode that has all the benefits of exclusive fullscreen (low latency, focused resources) and none of its drawbacks (slow Alt + Tab, HDR woes, etc.).

Kal doesn't even use G-Sync, as he prefers BFI, and those features are mutually exclusive on LG OLEDs (I have the same TVs as he does).

I was asking in more general terms, exactly because you're a G-Sync advocate/expert.

[jorimt]

I was asking in more general terms, exactly because you're a G-Sync advocate.

Yup, I don't know yet, as I haven't thoroughly tested Special K. I may do so once I receive an LDAT from Nvidia, but I don't have an ETA.

I'll certainly post any findings here if/when I do.

[Aemony]

My base tear-free G-SYNC recommendations remain the same.

The framerate limiting selection (regardless of any SpecialK FPS limiter findings) will remain a mix of individual user preferences and goals on a per-game basis.

I'm still a little confused about Special K's "SwapChain Management" settings, when used in conjunction with its framerate limiter, and how they should be configured for G-Sync-compatible displays. We should cap the FPS at -3 below the max refresh rate and define a backbuffer?

Kaldaien suggests a backbuffer count of 4, and a maximum device latency of 5 (which he says should always be backbuffer count + 1). He also suggests enabling "Waitable SwapChain", when using flip model presentation ("Enable DWM tearing" is selected by default). The thing is, he chooses not to use G-Sync, so I'm not sure how exactly those settings relate to VRR.

There's also a "low latency mode" in Special K (under the frame limiter tab) that I don't know how is related to Nvidia's own low latency mode (which I globally set to "On" = max pre-rendered frame of 1, per your and Chris' suggestions). Not to mention those sleepless threads options - no idea what they do.

Just trying to find the most optimal settings for SK, when combined with G-Sync, as I already have NVCP and RTSS down, thanks to your guides.

The number of back buffers doesn’t matter in VRR, as flip discard will always show the most recently rendered frame anyway. The additional back buffers only becomes relevant when hitting a output limitation (e.g. max refresh rate), as it would in those situations allow the game to render multiple frames unrestricted in the additional back buffers while still outputting the latest rendered frame on each refresh as I understand it.

Sleepless threads (window and render) is just to prevent games from using sleep() in said threads which can add additional micro-stuttering or in some cases even uncap the internal frame rate limiter of the game. Enabling both is merely for additional smoothing purpose, basically, as it prevents those from interfering with SK’s other manipulations.

Waitable swapchain allows, if I understand Kaldaien correctly, VRR to eliminate the slight frame variance of having V-Sync disabled — effectively removing the screen tearing at the bottom even when V-Sync is disabled. According to a comment from Kal, G-Sync On + V-Sync Off + Waitable Swapchain indicated (through the DXGI present statistics) a lower render latency than having G-Sync On + V-Sync On in his testing.

Remember that these findings are based on the preset statistics that DXGI exposes, and haven’t been confirmed using LDAT or other external measurements yet.

I haven’t really taken V-Sync Off + Waitable Swapchain combination out for a drive myself yet, but typically my preferred setup (maximizing frame pacing smoothness) is to run G-Sync On + V-Sync On (globally) + 4 back buffers and max 5 device latency, and then cap the game around 3-5 FPS of what I reach on average or so (with a minimum of 60 FPS).

Basically smoothest possible frame pacing with no real requirement to hit as high a frame rate as possible.

[EeK]

The number of back buffers doesn’t matter in VRR, as flip discard will always show the most recently rendered frame anyway. The additional back buffers only becomes relevant when hitting a output limitation (e.g. max refresh rate), as it would in those situations allow the game to render multiple frames unrestricted in the additional back buffers while still outputting the latest rendered frame on each refresh as I understand it.

Ah, that's what I've always wondered. So, if I limit the frame rate to 3/4 FPS below the max refresh rate, I'm essentially already creating back buffers, right? When capping the frame rate at G-Sync recommended settings, I can just set back buffers to -1 in SK?

Sleepless threads (window and render) is just to prevent games from using sleep() in said threads which can add additional micro-stuttering or in some cases even uncap the internal frame rate limiter of the game. Enabling both is merely for additional smoothing purpose, basically, as it prevents those from interfering with SK’s other manipulations.

Gotcha, makes sense.

Waitable swapchain allows, if I understand Kaldaien correctly, VRR to eliminate the slight frame variance of having V-Sync disabled — effectively removing the screen tearing at the bottom even when V-Sync is disabled. According to a comment from Kal, G-Sync On + V-Sync Off + Waitable Swapchain indicated (through the DXGI present statistics) a lower render latency than having G-Sync On + V-Sync On in his testing.

Remember that these findings are based on the preset statistics that DXGI exposes, and haven’t been confirmed using LDAT or other external measurements yet.

Oh, so waitable swapchain works as a substitute to VSync? When enabling the former, we should disable the latter?

I haven’t really taken V-Sync Off + Waitable Swapchain combination out for a drive myself yet, but typically my preferred setup (maximizing frame pacing smoothness) is to run G-Sync On + V-Sync On (globally) + 4 back buffers and max 5 device latency, and then cap the game around 3-5 FPS of what I reach on average or so (with a minimum of 60 FPS).

Basically smoothest possible frame pacing with no real requirement to hit as high a frame rate as possible.

By globally, do you mean on NVCP's "Global Settings"? What about the low latency setting under the frame rate limiter? And do you always leave "Enable DWM Tearing" unchecked?

[Aemony]

It seems that I might've said some incorrect stuff in my former post... just goes to show the complexity and the number of settings involved, and whether SK does things "automatically" or not when various settings are enabled -- not to mention how often Special K changes and whatnot.

I was mighty confused for a bit as well as Kaldaien have apparently also, in the past, mentioned how waitable swapchains didn't work with G-Sync enabled, but I assume it was in earlier versions of Special K before he added necessary logic to account for G-Sync/VRR scenarios...

It turns out that the waitable being tearing free though was in regards to using V-Sync Off + G-Sync Off + Waitable -- not actually G-Sync On. I highly recommend reading the full post for the below quote and context:

Waitable (tearing free) has about 1 ms more latency than G-Sync On + V-Sync Off (which includes tearing). This is after building a new VBlank undershoot feature into my limiter, it’s designed to present frames for composition a little bit earlier than normal VSync would. The distance between each frame is still constant, I’m just racing to get the frame queued for presentation ~4% quicker than VBlank.

In a way, this is like scanline sync, only I couldn’t care less about syncing to a particular scanline or turning V-Sync off, I’m just working to keep the DWM and application synchronized.

And another relevant quote about waitable swapchains:

Special K’s limiter with a Waitable SwapChain enabled is always checking how many queued frames are undisplayed and will remove queued frames over time to get the render latency down to 0-1 frames.

Previously Kaldaien have mentioned how Presentation Interval ("V-Sync") would need to be set to 1 for SK to drop frames, but that was back in September and the above quote is newer, so I don't think it applies any longer...

---

Ah, that's what I've always wondered. So, if I limit the frame rate to 3/4 FPS below the max refresh rate, I'm essentially already creating back buffers, right? When capping the frame rate at G-Sync recommended settings, I can just set back buffers to -1 in SK?

Leaving it to -1 will have the game use its default numbers of buffers (typically 2 or 3).

---

Oh, so waitable swapchain works as a substitute to VSync? When enabling the former, we should disable the latter?

Seems I was mistaken on this part, sadly. I took it for a spin yesterday without V-Sync enabled and while I didn't experience any tearing, according to Kaldaien it does still produce tearing so it seems I was wrong. I recommend seeing the above linked post for the whole context as well as settings Kaldaien used when he mentioned that tearing was experienced (TL;DR: G-Sync On + V-Sync Off + Waitable Swapchains).

---

By globally, do you mean on NVCP's "Global Settings"?

Yes, I generally adhere to Blur Busters' overarching recommended settings still.

---

What about the low latency setting under the frame rate limiter?

To quote Kaldaien again (it's probably best that I keep doing that, lmao):

Also, when using G-Sync always use the Low Latency Mode in the framerate limiter advanced tab. That changes when the limiting is applied, with it off the CPU creates a frame but it gets delayed until target fps.

With it on, the new frame doesn’t start until target fps. Basically, it polls input closer to the actual image going out onto screen… but it would cause unstable framerates w/o G-Sync.

Most games you might only get a 1-2 ms improvement

That’s why the framerate limiter has a low latency mode and an option to discard late frames.

For low latency, turn on:

Waitable SwapChain
Tearing in DWM
(-) Low Latency
(-) Minimum Latency

The two latency modes in the SwapChain settings are optional.

---

And do you always leave "Enable DWM Tearing" unchecked?

The relevance of that setting is only when two different windowed applications are on the screen simultaneously, apparently:

Also, this notion of “tearing” as it is referred to, is REQUIRED for G-Sync to work if you have two different window applications on screen at the same time. What this tearing flag refers to is the foreground window controlling the refresh rate of the DWM independently. Without that flag, if you have two different windowed apps visible at the same time, they get synchronized to one another.

You know that setting in NVCPL called “G-Sync in Windowed mode?” That driver hack is the same thing as this tearing flag.

---

To be honest, I think I sorta made myself confused as a result of writing this post. Special K has a lot of configurable options, and how they apply in various scenarios differs.

Kaldaien mentioned recently how he wanted to throw up a custom wiki on his site and one of the things I think we can improve upon is to mention overarching common configurations for various scenarios that users might be interested in, such as G-Sync (focus on frame pacing), G-Sync (focus on latency),V-Sync Off (focus on latency and tearing-free) etc because this just goes to show how confusing it can at times be.

[diakou]

I was mighty confused for a bit as well as Kaldaien have apparently also, in the past, mentioned how waitable swapchains didn't work with G-Sync enabled, but I assume it was in earlier versions of Special K before he added necessary logic to account for G-Sync/VRR scenarios...
---
To be honest, I think I sorta made myself confused as a result of writing this post. Special K has a lot of configurable options, and how they apply in various scenarios differs.

It is honestly very nice to see someone with heavy understanding of Special K such as yourself also somewhat confused lately. (I am constantly confused on the special k settings, half of it coming down to me being dumb, the other half just... confused heh)

Honestly - Kaldaien has been pumping out change after change after change at ridiculous pace. It is very hard to keep track of anything, I'm fairly confident even Kaldaien has lost track of his own stuff sometimes. When the framerate limiter and latency conquest comes to an indefinite stop after improvements from LDAT testing, I am very excited to attempt the usage of it in as many games I might see could benefit from it at a competitive stand-point (or a way to tell developers there definitely is possibility in improving your game if an external framework is able to!!!) I mean I even managed to convince my own game to finally add DirectX11 support from DX9. Just so at the very least, Special K could possibly support it for some small optimizations without having to beg the devs to do something they have very little interest in / see very little reward from.

Kaldaien mentioned recently how he wanted to throw up a custom wiki on his site and one of the things I think we can improve upon is to mention overarching common configurations for various scenarios that users might be interested in

I think the absolute best timing for this would be sometime after the LDAT testing! Trying to finally get a place where at least the most common stuff is asked and the easiest answered questions would have a better updated FAQ.

Could imagine a lot of stuff like;
Best settings for lowest latency regardless of minor visual drawbacks;
Best settings for lowest latency with smoothest possible visuals
Best settings for lowest latency with g-sync/vrr
Best settings for best framepacing/smoothness

etc etc etc, (though the way you wrote it seemed a lot better, I guess that's why you're the wiki master and not me )

[Darktalon]

A lot has changed the last few months.

The discord versions now support enabling Nvidia Reflex in most games.

There are also now exact frametime statistics built in to the advanced framelimiter section to help you fine tune the settings.

[hsEnter]

special k is tanking my fps like crazy in many games, for exemple in Ori and the will of the wisp my fps dips to 120 and stays here, without special k its a smooth 240fps at all time