Nvidia Inspector Frame Rate Limiter different versions explanation?

https://i.gyazo.com/9a9313c9018dc9fe47bf3ef6c1779ca3.png

I have no idea. The only thing I know is that the different settings can be measured using a 1000FPS camera, and that the results indicate that v1 + fast sync has lower latency compared to v1 without fast sync or to v2, but it's still higher than RTSS.

Overall:

In-game limiter: good latency reduction.
RTSS: small latency reduction.
v1 + fast sync: no latency reduction.
v2 or v1 without fastsync: latency increase.

Anyway, this doesn't matter if RTSS is not an option (either due to preference or due to technical reasons.) In that case, v1 + fast sync gives the least latency. As to why, who knows. It just looks like a "hidden" switch from the outside.

Due to the fast sync dependence however, it makes it a bad choice; it has stutter. So overall you're basically kinda screwed if you can't use RTSS.

 

Where's the "use 3d application setting" variable? causes partial tearing with G-Sync? what? turn it on in-game! If it causes partial tearing where it wouldn't on a normal display, only G-Sync is to blame.

Why are you still saying it depends on fast-sync? fast-sync was not always there. Why do you think they would add something that would hinder the functional operation of the limiter? If they did well damn that's a stupid move. But i don't agree as I don't need fast-sync enabled to see the difference.

 

I'm not sure what you mean. The image I linked to shows the results of the input lag measurements.

To remind you again: we were talking about input latency differences between different frame limiter inspector settings. Not about tearing or partial tearing.

This is how it works now. v1 without fast sync has as much latency as v2.

If you want to know why NVidia did this, you should ask them, not me. I'm just bringing you the news. Don't shoot the messenger, please.

 

You know what I mean. I mean, you keep advocating for that article and in it explains why "use 3d application setting" isn't used. If all possible variables are not used, its not a fair experiment.

I disagree with this, but what else is new right? I do not need fast-sync on to notice a difference between v1 and v2.

 

Ah, yes you can totally tell. Even using a 30FPS cap with 1/2 Vsync from RTSS improves latency on top of pre-rendered 1. Very surprising I didn't notice this before.

 

Erm, I tested V-SYNC OFF (“Use the 3D application setting” + in-game V-SYNC disabled) with Nvidia Inspector's stock v1 and v2 limiters in my article:
https://i.gyazo.com/7c350d643d8cb551c69e3a81f0ee5059.png

That's exactly the scenario you specified, and it adds up to two frames, even with V-SYNC OFF.

The above quote shows you claim to have read the article, but you obviously didn't (or didn't pay attention), because I never said anything about not using "use 3d application setting," so your "its not a fair experiment" comment doesn't have a foundation here, at least in that context.

In fact, all the V-SYNC OFF results in the article (including G-SYNC + V-SYNC "Off") were “Use the 3D application setting” + in-game V-SYNC disabled.

I noted this directly in my article:

And:

The image RealNC linked was a forum-exclusive chart that I did after all of my other tests. I had to retain a proper control while testing, and couldn't update drivers until I was finished. That new setting has a 1 frame latency reduction when combined with G-SYNC (more likely a driver flag responsible, not Fast Sync itself, who knows), but that's not saying much, since stock v1 and v2 add up to 3 1/2 frames of delay with G-SYNC enabled. I ran out of time to test all variables for that very specific scenario in the forum post.

That new setting may or may not allow a reduction over the stock v1/v2 with standalone V-SYNC or V-SYNC OFF. All I know is the stock, out-of-the-box v1 and v2 limiters (sans the new setting, which hasn't fully been tested and may not stick/last for later driver releases) add at least two frames of latency no matter what syncing method or lack thereof you use.

I think there is a reason Nvidia doesn't expose the limiter officially; it isn't ready for primetime, especially when used with G-SYNC.

 

All i will say is that when VRR becomes a connection medium feature and not a GPU driver feature that requires extra hardware in the display, there will be a change in these results as anything driver controlled (including G-Sync) adds overhead/delay to an application.

Taking as much work off of interpreting hardware into software needs is what needs to be focused on overall.

 

I don't want to argue here, or drag this out longer than needed, but I'm slightly confused by your "All i will say is that when VRR becomes a connection medium feature and not a GPU driver feature that requires extra hardware in the display, there will be a change in these results" comment.

If you are saying that if Nvidia finds a way to limit framerate outside of the driver, then yes, I agree, the results will change, but if you're saying if Nvidia finds a way to achieve G-SYNC outside of hardware AND the driver, that the results of my test would change with the Nvidia framerate limiter, then no, they wouldn't.

V-SYNC OFF is literally no sync. This means it's not being controlled at a hardware or driver level, in fact, there is nothing to control, as it merely represents the raw output of the system. Even there, the framerate limiter adds "overhead/delay."

FreeSync's driver-level limiter (which, unlike Nvidia's, is officially supported/exposed) adds 2 frames of delay as well.

If a framerate limiter can't intercept render time at the engine-level (dictate render time before the frame is rendered), then it can't avoid delay, or at least reduce latency, whereas in-game limiters can, plain and simple.

RTSS can basically break even in this respect being at CPU-level, but I personally don't see how Nvidia or AMD can create an as low or lower latency limiter, since they only have access to the system through drivers/GPU.

 

v1 is the CPU limiter. v2 is the driver limiter.

 

Are you saying the new v1 option is on CPU side, or are you saying the v1 limiter has always been on CPU side? If it's the latter, it does a poor job of reducing latency over the v2 driver side limiter, at least going by my tests, where they are basically a wash.

Again, I'd have to test the new v1 option more thoroughly with non-G-SYNC scenarios, but I don't have an ETA on that. All I know now, is CPU side or not, Nvidia's limiter should not be paired it with G-SYNC, at least where RTSS can be used instead.

 

It's the latter. Somewhere after driver 368 or 2.1.x.x profile inspector both limiter options produce the same limiting behavior (force vsync off and both limiter versions would hold the tearing line like there was a third buffer being used).

v1 (with profile inspector 2.1.3.6+) now limits the framerate like it did before those versions (inconsistent frametime but less delay with variating tearing line just like RTSS produces). It was around the time Fast-Sync was introduced into the driver (which also uses a third buffer). It was probably a flag issue with profile inspector or a problem in the drivers itself. A good indicator of this is if you use GoW 4's benchmark (yes i know this has an in-game frame-limiter), v1 limiter should throttle at the CPU/Draw stage and v2 should throttle at the RHI.

Since G-Sync and profile inspector's frame-rate limiters work through the driver (although one controls the rate at which the CPU feeds the driver frames and one controls how fast the GPU renders them), I would concur that it might have a different effect than using a different limiting method such as RTSS, when using G-Sync.

I make the claim that since G-Sync is not universal, people should not use these test results as universal proof that the driver's limiters are worse than an external program such as RTSS.

G-Sync aside, using RTSS means the program will need to be kept running and poll/hook the application its limiting in the background. This creates a seperate process as it takes CPU cycles (delay). The v1 or v2 limiter work from the driver and does not create a seperate process for it to take CPU cycles from, rather it throttles it in the render pipeline. The difference between the versions is at what stage it throttles.

 

I don't think the RTSS frame limiter runs in a separate process. It should run in the same process as the game its applying the frame limit to.

It is my understanding that when you hook a function call, the game calls the function, not RTSS. (That's the whole point of hooking a function.) The function call is executed in the game's process.

That means there should be no delay due to process scheduling and the RTSS process has no impact on game performance.

 

RTSS.exe will be running in your task manager which is a 'separate' process. When it hooks and polls an application, it basically inserts itself between the driver and application. When the driver's frame limiters are enabled, they don't create a separate process.

Any software that polls hardware will cause delay as it has to travel through the processor to read the other components in your PC. For example, netgraph in source (polls the network interface), Statnet/StatFPS in Unreal Engine (polls the network interface or GPU).

This is why I don't leave RTSS for onscreen resource usage or game specific commands to observe my latency/fps running all the time.

 

The frame limiter doesn't poll the application. It runs in the process of the application.

If you're referring to the OSD statistics, that is a separate thing. You can use the frame limiter even with OSD support set to "disabled".

If on the other hand you're referring to application launch detection, why would RTSS poll for that if it can just use WMI to get notified of process starts? That's how I do it. Polling all the time for that doesn't make sense, and it's less accurate (you can miss events.)

 

Now I think we're getting to the crux of your personal issue with using RTSS; you contend it has a performance impact.

My understanding is that RTSS performs the injection process once; it is not continual. Also, I'm pretty sure RTSS only takes up idle CPU cycles in-between game processes, and while this can show as higher CPU usage in overlays, it isn't actually affecting performance, otherwise this would show on benchmarks (which to my knowledge, it doesn't).

G-SYNC or no G-SYNC, the Nvidia limiter may have obscure uses, and it of course may be the only option if an in-game limiter isn't present, or RTSS can't be used for whatever reason, but I have yet to come across a scenario where the Nvidia limiter matches RTSS latency levels, let alone beats them.

My question at this point is if you personally can't discern a latency difference between RTSS and Nvidia's limiter, why do you care to defend the latter?

I'm all for choice (the user may implement whatever method they wish), but thus far, Nvidia's limiter is plain old laggier than RTSS, and I'm not certain why this fact has become so contentious.

 

Delete

 

Well i personally can, but thats just me right? Without executing anything, RTSS is sitting there polling for something to hook onto. You close it and notice a slight reduction in delay from your mouse.

The latter is just a set and forget. It works without needing a process running. Again because used in tandem with G-Sync which also works in the driver, it could have negative effects (as shown by your data) than using it with a non-G Sync display.

 

I don't believe RTSS is affecting the mouse response at all when being used as an overlay only, or idle on the desktop. It only adds <1 frame of delay when being used to limit the framerate, and only when it is the limiting factor.

As for Nvidia's limiter, what's the use of its process-less "set and forget" over RTSS if it adds at least 1 more frame of delay, even in non-G-SYNC modes? And for arguments sake, let's say RTSS is adding polling delay to the mouse (which I can't prove at this point one way or the other); if it's still lower latency than the Nvidia limiter, even with the supposed mouse lag, what does that or the fact that RTSS is a separate process matter?

The bottom-line is RTSS currently has less net lag than Nvidia's limiter. Your distaste on how it achieves this doesn't change that fact.

 

With G-Sync maybe so, but universally?

 

So again, you didn't look at my standalone V-SYNC OFF results?

Nvidia's limiter with V-SYNC OFF showed nearly a 2 1/2 frame delay (both v1 and v2) over V-SYNC OFF with an in-game FPS limit (https://i.gyazo.com/7c350d643d8cb551c69e3a81f0ee5059.png), which was about a 1 1/2 frame delay over RTSS in the same scenario (https://i.gyazo.com/babe29dc93820cdc1b2562e9677b5c4d.png).