Do you use Nvidia's Driver Limiter or RTSS to limit your framerate? Any pros and cons to either?

No offense to that Blurbusters guide, but the guy is missing some key points in there and doesn't even mention them, for example changing NVCP latency with g-sync does have an effect in different games (in Ultra for example, when it comes to DX11, g-sync module already lowers 2 frames from the original monitor's refresh rate WITHOUT THE NEED OF ANY LIMITER) and he could have suggested people to try and switch that as well. Also I've seen some technical questions made to him in the forum and he doesn't seem to be quite sure what he is explaining and seems to be just guessing. Also the "need" of v-sync with g-sync is relative, it depends on the game, your framerate cap and other things, you don't need v-sync with g-sync if you are already using a framerate limiter such as RTSS or the one from Nvidia. V-sync on g-sync can help prevent tearing with a framerate limiter, but is not needed and not all games present tearing so this is PER GAME, you need to try it individually, Blurbusters "global" g-sync setttings are botched imo and should be followed with caution as NOT ALL GAME engines respond the same, also SOME games dislike or straight up hate framerate limiters and in those cases, you need to settle with v-sync and g-sync, no framerate limiter or you will have a lot of small stutters and bad frametimes.

 

i guess i also post my experience

there are several ways to limit your frames, from driver to ingame setting to RTSS and specialK, probably more.
i only tested those above and while mostly using the Driver (nvidia frame limiter v3) to limit my games. But there are games (maybe its my hardware too) where using a diff. one helps a lot in frametimes and latency. if you are playing dx11/12 games i would use SpecialK to limit the frames, its the best one ive seen yet if supported and it has a lot of neat features to get even more out of it. i never had such low and stable frametime ever.. not with driver based limiting, inside teh game, nor with RTSS.

if you would want me to rate them (even though it depends heavily on the game, engine etc and some might work better then others etc) id say:

specialK / RTSS
In Game limiter
Driver based limiter

but like i said, it heavily depends on the game you are playing and the hardware / config you are using. So you cant really rate them from worst to best id say..
anyway, the most impressive experience i had with SpecialK and RTSS in regards to variations and other metrics..

here is some info about specialK if you are interested:
https://wiki.special-k.info/en/Advanced/Video

and the swap chain science
https://wiki.special-k.info/en/SwapChain

added 2 pics i found - one with NVidia Driver Limiter and one with specialK

NVIDIA Driver Limiter:


SpecialK Limiter:


take a look at the "variation" value for example.
Best to test it yourself and see what it can do for you, but be aware, its a bit harder to use then RTSS or other solutions since it can do so much more. (replacing textures and ripping them for example)

 

Double-buffer is the preferred mode with g-sync. Forced triple-buffer vsync is another reason the recommendation was to disable in-game vsync (hoping that driver-forced vsync will result in double-buffering.)

With that being said, there is no known drawback with triple-buffering in an FPS-limited situation. The third buffer is virtually always drained immediately due to the FPS cap. But still, why have it to begin with.

This didn't exist when the article was written. Also, it's not 2 frames. It's only 2 frames when running at 60Hz. At 144Hz it's 6 frames (138FPS). At 240Hz it's something like 16 frames IIRC (224FPS.)

Especially 240Hz g-sync users sometimes prefer to cap to 236FPS instead (in games that can run that fast) and set low latency mode to "on" instead of "ultra." It's a trade-off, of course. "Ultra" doesn't do anything if the cap is reached (latency is minimal already there,) but helps when the GPU can't reach the cap (the high GPU load results in backpressure, which "ultra" then mitigates.)

 

The latest version of my recommendations have included that for a very long time now:

That, and the "Ultra" auto limiter doesn't always engage, and is game-dependent, so I still can't recommended it as a primary global limiting method unless it is verified as working per-game.

For instance, someone else suggested it in my comments a while back, and I responded with a test of my own to exhibit how impractical it can be:

--------

It's less that I'm guessing (though you didn't provide examples of this), and more that questioners usually don't fully know what they're asking, which makes it very difficult to answer.

LLM/Reflex settings and G-SYNC settings are technically separate and address distinct forms of latency, the former being render queue-related, and the latter being sync-related, and both can stack, but visitors are constantly conflating them as the same thing.

It's mere logistical coincidence that Nvidia decided to overlap them settings-wise when used with G-SYNC.

You do if you never want to see tearing inside the refresh rate, which will occur with G-SYNC on + V-SYNC off; the severity and frequency of tearing artifacts in this scenario will simply depend on the given frametime performance of the game, something that G-SYNC on + V-SYNC on accounts for and G-SYNC on + V-SYNC off doesn't.

There's more on this in the #2 entry of my "Closing FAQ."

And? I say as much in my article.

Providing a per-game recommendation in a single article is impractical, thus I had to resort to a more general blanket recommendation (though still with some else/if cases) that covers the broadest scenario possible.

Regardless of per-game quirks, base foolproof tear-free G-SYNC recommendations for 99% of games will always be G-SYNC on + NVCP V-SYNC on + a minimum -3 FPS limit below the current max refresh rate.

As for my limiting method recommendations, they prioritize limiters in the order of lowest latency, and are primarily in-place to keep G-SYNC active at all times, not to address any additional render queue latency unrelated to sync latency, which can be separately addressed with methods like LLM, Reflex or a lower manual FPS limit.

Everything else is secondary where proper manual G-SYNC configuration and sync latency is directly concerned, and is ultimately up to the individual user's given hardware, priorities, and preferences.

--------

Anyway, getting back on thread topic, RTSS and NVCP MFR are now comparable in both latency and frametime performance, so you can't really go wrong with either if you don't wish to use the in-game limiter for whatever reason, be it because one isn't available, or it is poorly implemented.

That said, whether you use RTSS or MFR can also depend on how the game reacts, in which case the only recommendation is to try both and subjectively pick what feels best per, regardless if both limiting methods are now effectively equal technically (though MFR is probably more immune to being flagged in cheat engines, whereas RTSS has more options and secondary capabilities, etc).

 

Out of curiosity, is it possible that g-sync + triple buffered v-sync could result in a "smoother" looking presentation since we're buffering ahead by one more frame? I'm just still really curious about what the heck was going on with Metro. Of course there's likely a latency trade off and I could be wrong in even suggesting this since G-Sync I would think would remove any benefit from additional frame buffers (though I could be wrong there, I'm unsure), but it makes me wonder since specific games don't seem to like g-sync + driver level v-sync and prefer in-game v-sync (though this seems to be a rare occurrence).

 

Thanks for your work testing all of this, it's incredibly useful.

 

Some interesting insights from Digital Foundry's 4090 review (#2 is G-Sync related, #1 I just felt like including though it's not really relevant for this thread):

1) Rich said AMD often does better when CPU bound (are we circling back to that "Nvidia driver overhead" problem HWU mentioned sometime ago?)

2) Rich also said towards the end of the video that driver vsync can cause camera stutter with gsync in some cases and vsync won't be supported in-game with dlss frame generation and iirc he also said Nvidia wants it used with uncapped framerates (so doesn't that mean you'll get tearing with g-sync if you use frame generation?)

 

Thanks for this, very helpful -- I read through some of the swap chain link and, one thing in the v-sync FIFO section doesn't make sense to me. They say this there:
> "We see no reason to ever use the traditional FIFO queuing behavior on a desktop machine in any graphics API that has the ability to skip old frames (e.g. D3D10/11/12 and Vulkan)."

In that section aren't they just arguing that they prefer Fast Sync style triple buffering where intermediate frames are dropped and the most recent frame is displayed instead? Frankly I cannot stand non-FIFO V-Sync because dropping the intermediate frames causes a lot of visible "jitter"/microstutter in my experience.

 

It's always stupid when "some cases" isn't specified further. Can only say I've never seen this.
Also can't confirm your findings with vsync in Metro EE. The game simply runs with crap frame times on Nvidia vs. AMD, no matter the vsync mode. RTSS frame time graph in the beginning of the Volga level just looks catastrophic, I really doubt this disappears with in-game vsync.

 

Probably a difference in our systems I expect. I can tell you with certainty in Metro Exodus Enhanced Edition with near max quality settings/RT that using G-Sync + in-game V-Sync ON totally fixed microstuttering in the same exact areas vs using g-sync + driver v-sync. I tested this on my 3900X + 2080S system repeatedly towards the end of the game. In fairness, I have never seen this behavior in any other game to my recollection. They also may have patched that title since this was sort of nearer to the EE launch iirc and Nvidia drivers have also changed so who knows, I'd need to restest it at this point.

In that DF video you're correct that Rich did not specify as he mentioned it was one of Alex's findings for an upcoming video if I remember correctly but the fact that they said it at all lends some credence to this being the case in "some cases" seems to me.

I did not perceive a difference in RTSS "frametime" output readings, but there was a very apparent difference in camera animation smoothness/camera stutter in my tests. Unwinder said in another thread that the frametime graph being flat does not guarantee smooth camera motion. For context, I tested this in that late game fall trees and leaves area after you ride the train quite a ways. One thing I wonder is perhaps my system was more CPU bound or some such -- that system did not have very fast RAM paired with the 3900X regrettably. Really could be quite a large number of differences I suppose.

 

Just tested it with in-game vsync, can unfortunately feel the stuttering without a doubt:


The game is just broken on Nvidia, unless VKD3D-Proton is used:
https://forums.guru3d.com/threads/n...wnload-discussion.440032/page-12#post-5955437

 

Maybe that's the issue i experience with RTSS limiting in older games.

Perhaps a driver issue.

 

It is not related to RTSS, feels also stuttery without RTSS inject.

 

With uncapped FPS, which is when the third buffer comes into play, sure. But with capped FPS, that third buffer is always presented right away. You're not gonna run into a situation where there's two framebuffers still waiting to be presented. That's if there's even a third buffer. I don't know what the driver does when g-sync is active. It might be not even be using three buffers. I don't know, and nobody tested

 

I appreciate your testing it, that's great to know your experience there.

 

Thanks!

 

Did some more testing: I can actually confirm your observation that enabling vsync in-game helps frame time variance, i.e. reduce perceivable stutter. This is in-game vsync on vs. off:


However, the issue is not caused by forcing vsync via driver. It is more like the game does something wrong when vsync isn't activated in-game. Frame times also get better when enabling vsync in-game and enforcing in driver at the same time, and are worse without any vsync. Really weird issue. Though also with enabled in-game vsync, it's still worse than VKD3D-Proton or AMD D3D12.

 

HWU wasn't hitting cpu bottlenecks, they were starving the gpu of work to do so segments were asleep/low power.

 

Hello
What overlay do you use to show variation, bottom right in your screenshot?

 

That is SpecialK