NV DB Vsync + RTSS limit

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: NV DB Vsync + RTSS limit

Post by Chief Blur Buster » 20 Feb 2017, 16:58

Sparky wrote:Those were CRT based tests, I haven't done any testing with modified signal timing. As for high vertical totals impacting latency, I suppose that would depend on when exactly the video card does the buffer flip, hopefully in the front porch. If it does it at the start of the back porch then high vertical totals would actually increase lag. Either way, it won't be a big impact, about half a refresh interval if you can double the normal pixel clock. Still really interesting, sounds like a big benefit to pulsed backlights.
Clarification: Back Porch is before the top edge of the display and Front Porch is after the bottom edge of the display. Yes, page flip timing during the synchronization interval will play a big factor.

Yes, some of the 240Hz TN monitors supports double-sized blanking intervals at 120Hz -- basically as huge as the active image itself -- meaning 1/2 of the time a frame is being delivered to the monitor (A 120Hz refresh cycle in 1/240sec) and 1/2 of the time is a mondo super-long blanking interval.

The Custom Resolution Utilities are flexible enough to allow you to add the padding to either Vertical Back Porch, Vertical Sync, or Vertical Front Porch. So in theory, you can pad where it matters to allow the page flip to occur where you prefer it to occur. Unless the page flip occurs immediately at the instant of Front Porch (i.e. right after scanning-out the 1080th row of pixels on 1920x1080) -- which is bad, and creates a latency penalty because we're forced to wait through the long synchronization interval before it begins scanning out visible to the displaqy.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: NV DB Vsync + RTSS limit

Post by Chief Blur Buster » 20 Feb 2017, 17:03

Oh, and if we use GSYNC, we can simply bypass this problem completely. We'd simply frame-cap and it'd look exactly like VSYNC ON, but with much lower lag than VSYNC ON.

GSYNC + fps_max capping -- looks exactly like VSYNC ON -- but with less lag -- because GSYNC already does maximum-DisplayPort-speed frame delivery, regardless of current refresh rate, dynamically varying the interval between refresh cycles. The frame becomes visible as soon as it's being delivered. So the magic sauce is probably GSYNC + fps_max for a low-lag "VSYNC ON" experience, assuming the frametime jitter isn't too bad.

However, varying rendertimes inserts a varying lag to frame-capped GSYNC even if it's running flat out consistent at frame cap, because rendertimes can still vary quite a lot.

For consistent lag during GSYNC + fps_max, you would want the frame capping utility to do an intentional busywait if the rendering completes very fast. e.g. If your fps_max target is 120 and you're running a game engine capable of 500fps, you'd target a 2ms render window, and if a render occurs

I wonder if any frame-capping utility developers (or NVIDIA or game developer who develops the in-game frame cap) has already done this sort of thing -- i.e. the insertion of intentional precise busywaiting (e.g. while (MicrosecondTimer() < TargetTime) { /* busywait; loop until target time */ } ) during rendering to force exact rendertimes (as long as GPU rendertime is less than user-specified rendertime target). No matter how faster-than-expected the frame renders. That would in theory allow exact input lag (<1ms latency jitter in theory) + GSYNC + fps_max, for a low-latency VSYNC ON experience with consistent fixed (non-varying) input lag, perhaps a much flatter graph. Basically using capped-out GSYNC instead of using VSYNC ON -- using GSYNC with consistent (capped) framerate as a method of lowering VSYNC ON input lag.

Adding input lag intentionally is anathema to a lot of programmers, but when we're doing 500fps+ in CounterStrike:GO on Titans and 1000 series GeForces -- it's just a 2ms rendertime window we're aiming for.

So if rendertime is 1.4ms, we intentionally busywait for 0.6ms (either on GPU or on CPU) to maintain perfect timing of input read for the next frame render (potentially microsecond-accurate), to force an exact 2.0ms rendertime.

If a frame capping programmer wanted to go elaborate Full Monty to target a Holy Grail, and want to inject a realtime shader modification into existing games (ugh, this would violate anti-bot anti-cheat guards, and not be allowed for online competition gaming), one could in theory do it. You'd use microsecond-accurate clocks on a GPU using shader logic (e.g. OpenGL glutGet(GLUT_ELAPSED_TIME) etc) and loop based on that to force precise rendertimes for frames on a GPU. Or whatever DirectX/etc equivalent. Every frame taking less than exactly 2ms, would be forced to render in exactly 2ms (plus or minus a few microseconds) and produce amazingly flat FRAPS graphs in certain games. Perfectly predictable input lag of perfectly constant 2ms, which is often much easier to aim for, than a varying input lag randomly jumping 0 through 4ms. Assuming all other factors weren't adding microstutter... The game engine will be a big problem, but what you want is a precise time between the input read & the VSYNC time, so using any trick to force that would be a benefit. Some game engines do an input read almost immediately right after returning from VSYNC, so forcing a busywait into that logic (e.g. either a CPU busywait loop or shader busywait loop that executes upon call to VSYNC page flip, to force a precise fixed delay after VSYNC before returning to the game app, to force the game to do an input read closer before the next VSYNC interval... depends on game engine's timing of input read... It'd work mainly with game engines that do the input read (for next frame) immediately upon returning from a page flip). This would in theory result in consistency-low-latency VSYNC ON (if disabling multicore rendering & using shortest possible frame queue) or consistency-low-latency fixed-framerate GSYNC.

I'd dare bet that competition gamers would prefer latency-variability-reduction, e.g. given the choice, preferring an added exact +2ms latency penalty (easier aiming), rather than variable added +0ms-thru-+4ms latency penalty (throws off aiming) -- 1ms of unpredictable latency adds a 2ms of mis-aiming error during 2000 pixels/second fast-aiming. So 4ms of unpredictable latency variability range (e.g. varies from 20ms thru 24ms) can mean you can mis-aim as much as 8pixels during 2000 (math: 4/1000ths of 2000 = 8 pixels) pixels/second fast-aiming -- that is approximately one-screen-width in 1 second. Meaning you won't correctly shoot that far-away enemy as quickly, because you have to do back-n-forth aiming corrections before pulling the trigger...

Now if only monitor manufacturers would release strobed GSYNC... Getting blur reduction at the same time as GSYNC. Frame-capped GSYNC (below GSYNC max) is much lower latency than traditional VSYNC ON, so this would be a good way of getting the majority of the VSYNC ON experience without the lag.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

knypol
Posts: 76
Joined: 18 Aug 2016, 03:40

Re: NV DB Vsync + RTSS limit

Post by knypol » 19 Apr 2017, 15:11

New version of RTSS has been released..any1 got idea how to enable floating point framerate osd display?

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: NV DB Vsync + RTSS limit

Post by RealNC » 19 Apr 2017, 19:34

knypol wrote:New version of RTSS has been released..any1 got idea how to enable floating point framerate osd display?
Make sure RTSS isn't running. Then, in the RTSS installation directory, open the file "Profiles\Global" in Notepad. Add this in the [OSD] section:

IntegerFramerate=0

You might have to run Notepad as admin.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

chiaisthewei
Posts: 3
Joined: 04 May 2017, 12:07

Re: NV DB Vsync + RTSS limit

Post by chiaisthewei » 04 May 2017, 13:08

I'd like to clarify something about limiting framerates using RTSS below display refresh with VSync On. The difference between the limited framerate and the display refresh will eventually manifest as a dropped or double frame display, i.e. stuttering?

I really wanted to understand the concepts behind this, so based on the videos/materials I've seen, I made the following illustration - are the concepts there correct?
Presentation1.png
Presentation1.png (109.25 KiB) Viewed 6624 times

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NV DB Vsync + RTSS limit

Post by Sparky » 04 May 2017, 15:05

chiaisthewei wrote:I'd like to clarify something about limiting framerates using RTSS below display refresh with VSync On. The difference between the limited framerate and the display refresh will eventually manifest as a dropped or double frame display, i.e. stuttering?

I really wanted to understand the concepts behind this, so based on the videos/materials I've seen, I made the following illustration - are the concepts there correct?
Presentation1.png
vsync on with cap is accurate, though the frame rendering would likely not be aligned in phase with the start of a refresh(at least I'm not aware of a tool that is capable of it).

Vsync on(no cap) is a bit off. Normal vsync would display every frame(wouldn't skip frame 2), and would limit framerate via backpressure, resulting in several frames worth of buffering/input lag. At the very start of rendering though, the pipeline is empty, so f1 would display on the first refresh cycle, f2 on the next, and so on. Only when the whole pipleline is full does the framerate become limited. Maybe when you're displaying frame 10, frame 15 starts rendering, and the backpressure stops it there. If you're looking at steady state uncapped vsync, take your "vsync on capped exactly at refresh rate" and add 4 or 5 to the gray boxes.

fast sync or full screen windowed will drop extra frames instead of displaying them and limiting framerate. It should display f1 on the first refresh, f3 on 2nd f4 on 3rd f5 on 4th f6 on 5th, f7 gets skipped over, and f8 on the 6th refresh. Though there could still be buffering in the driver if you're GPU limited.

chiaisthewei
Posts: 3
Joined: 04 May 2017, 12:07

Re: NV DB Vsync + RTSS limit

Post by chiaisthewei » 05 May 2017, 02:44

Sparky wrote:
chiaisthewei wrote:I'd like to clarify something about limiting framerates using RTSS below display refresh with VSync On. The difference between the limited framerate and the display refresh will eventually manifest as a dropped or double frame display, i.e. stuttering?

I really wanted to understand the concepts behind this, so based on the videos/materials I've seen, I made the following illustration - are the concepts there correct?
Presentation1.png
vsync on with cap is accurate, though the frame rendering would likely not be aligned in phase with the start of a refresh(at least I'm not aware of a tool that is capable of it).

Vsync on(no cap) is a bit off. Normal vsync would display every frame(wouldn't skip frame 2), and would limit framerate via backpressure, resulting in several frames worth of buffering/input lag. At the very start of rendering though, the pipeline is empty, so f1 would display on the first refresh cycle, f2 on the next, and so on. Only when the whole pipleline is full does the framerate become limited. Maybe when you're displaying frame 10, frame 15 starts rendering, and the backpressure stops it there. If you're looking at steady state uncapped vsync, take your "vsync on capped exactly at refresh rate" and add 4 or 5 to the gray boxes.

fast sync or full screen windowed will drop extra frames instead of displaying them and limiting framerate. It should display f1 on the first refresh, f3 on 2nd f4 on 3rd f5 on 4th f6 on 5th, f7 gets skipped over, and f8 on the 6th refresh. Though there could still be buffering in the driver if you're GPU limited.
I see. Thanks for the clarification regarding frame buffer and backpressure!

So in practical terms, GSync below the max refresh rate is the best experience in terms of latency and tearing (lack thereof).

If I want the next best alternative without a GSync monitor, like the others said before, capping the framerate for VSync On will basically reduce the number of buffered frames, and thus the input lag experienced. But that comes at the cost of less consistent input lag/frametime depending on (1) how fast my GPU can consistently render frames and (2) the discrepancy between limited framerate and actual display refresh rate. For (2), assuming no frame drops due to other issues and a good limiter (RTSS?), the discrepancy results in a periodic dropped frame every 1/(Display Refresh Rate - Limited Frame Rate), like 1 dropped frame per second for 59fps on 60Hz, so setting it to 59.993 fps (in RealNC's case) on 60Hz will theoretically only drop a frame every 142 seconds?

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NV DB Vsync + RTSS limit

Post by Sparky » 05 May 2017, 03:51

chiaisthewei wrote:
Sparky wrote:
chiaisthewei wrote:I'd like to clarify something about limiting framerates using RTSS below display refresh with VSync On. The difference between the limited framerate and the display refresh will eventually manifest as a dropped or double frame display, i.e. stuttering?

I really wanted to understand the concepts behind this, so based on the videos/materials I've seen, I made the following illustration - are the concepts there correct?
Presentation1.png
vsync on with cap is accurate, though the frame rendering would likely not be aligned in phase with the start of a refresh(at least I'm not aware of a tool that is capable of it).

Vsync on(no cap) is a bit off. Normal vsync would display every frame(wouldn't skip frame 2), and would limit framerate via backpressure, resulting in several frames worth of buffering/input lag. At the very start of rendering though, the pipeline is empty, so f1 would display on the first refresh cycle, f2 on the next, and so on. Only when the whole pipleline is full does the framerate become limited. Maybe when you're displaying frame 10, frame 15 starts rendering, and the backpressure stops it there. If you're looking at steady state uncapped vsync, take your "vsync on capped exactly at refresh rate" and add 4 or 5 to the gray boxes.

fast sync or full screen windowed will drop extra frames instead of displaying them and limiting framerate. It should display f1 on the first refresh, f3 on 2nd f4 on 3rd f5 on 4th f6 on 5th, f7 gets skipped over, and f8 on the 6th refresh. Though there could still be buffering in the driver if you're GPU limited.
I see. Thanks for the clarification regarding frame buffer and backpressure!

So in practical terms, GSync below the max refresh rate is the best experience in terms of latency and tearing (lack thereof).

If I want the next best alternative without a GSync monitor, like the others said before, capping the framerate for VSync On will basically reduce the number of buffered frames, and thus the input lag experienced. But that comes at the cost of less consistent input lag/frametime depending on (1) how fast my GPU can consistently render frames and (2) the discrepancy between limited framerate and actual display refresh rate. For (2), assuming no frame drops due to other issues and a good limiter (RTSS?), the discrepancy results in a periodic dropped frame every 1/(Display Refresh Rate - Limited Frame Rate), like 1 dropped frame per second for 59fps on 60Hz, so setting it to 59.993 fps (in RealNC's case) on 60Hz will theoretically only drop a frame every 142 seconds?
correct. input lag would jump up by one frame every time you miss a deadline, then creep down until you miss another deadline. Assuming perfectly consistent frame times.

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: NV DB Vsync + RTSS limit

Post by RealNC » 05 May 2017, 05:23

Basically no dropped frames due to the cap, since the game itself will drop frames more often. The one frame every 2 minutes gets buried among the many dropped frames due to the game stalling from time to time (loading assets, multitasking, FPS drops, etc, etc, etc.)
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: NV DB Vsync + RTSS limit

Post by Chief Blur Buster » 05 May 2017, 09:43

Sparky wrote:vsync on with cap is accurate, though the frame rendering would likely not be aligned in phase with the start of a refresh(at least I'm not aware of a tool that is capable of it).
I think we need a framerate capping utility with configurable options optimized for older games that intentionally delays returns from VSYNC in VSYNC ON. Like.... A configurable intentional post-buffer-flip delay.

An intentional delay that reduces input lag!

How? Allow me to explain: By delaying after the page flip (e.g. A specific special mode where VSYNC ON waits longer in order to reduce VSYNC ON lag -- basically a glFlush()/glFinish() call doesn't return right after page flip) -- we can force the game to do a later input read & render next frame closer to NEXT refresh cycle. We prevent the game engine from executing an input read (too early) until closer to the next refresh cycle. The frame can be rendered much closer to the next refresh cycle. Less lag between input read and refresh cycle. And VSYNC ON input lag is thus reduced -- this can especially be useful to eliminate the lag during GSYNC maximum frame rates, e.g. eliminate the lag penalty for hitting the GSYNC maximum frame rate.

This will only work if frame rendertimes are tiny (e.g. Quake/CS:GO/old games) or if you can accurately predict the render time (to avoid missing the refresh cycle of a fixed-Hz monitor) or if the monitor is happy to slightly delay the next refresh cycle (e.g. GSYNC/FreeSync) in the situation of mis-predicted rendertimes.

This would probably only work for single-threaded rendering pipelines, and older engines -- like CS:GO running in single-core mode. VSYNC ON with less input lag.

For certain games, it would eliminate the need for frame capping utilities during GSYNC operation (or even for low-lag VSYNC ON operation on fixed-Hz monitors) -- Only for some games that behave very well with this.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply