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
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: NV DB Vsync + RTSS limit

Post by RealNC » 05 May 2017, 09:55

GeDoSaTo does this:

http://blog.metaclassofnil.com/?p=715

It only works for DX9 games.
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:58

chiaisthewei wrote:Image
Fantastic illustration!

I believe it looks mostly correct -- except for some clarifications.
--> "Vsync On No Cap" is really "Fast Sync" or a form of triple buffering (the low-lag kind), and F-numbers should be shifted 1-left. (I think).
--> "VSYNC ON" capped to refresh rate, is regular "VSYNC ON" -- it's self-capping. Pre-capped. API's with VSYNC ON waits to flip before returning to game.
--> First row really should be called "Default VSYNC OFF Behaviour" (or something like that)
--> Fourth row really should be called "Default VSYNC ON Behaviour" (or something like that)
--> First and Fourth rows should probably become First & Second Rows, because they're the most common settings.
--> VSYNC ON can vary quite a lot. I've seen slightly lower-lag VSYNC ON occur (F-numbers shifted 1 left) and higher-lag VSYNC ON occur (F-numbers shifted 1 or 2 right -- especially with higher "Queue Depth" numbers)
--> Second row is the least accurate, but may be occuring with Borderless Windowed + Compositing + VSYNC OFF. (compositing converts VSYNC OFF to VSYNC ON look).

Other than terminology clarifications, and row #2, your graph looks correct.

Also, "Fast Sync" in full screen is similar behavior to: Borderless Windowed Mode + Windows Compositing + VSYNC OFF (which can have similar tearing-free "Fast Sync" behavior) ... However, there can be extra lag caused by compositing overhead which shifts all the F-numbers 1 refresh cycle forward (though it may not be this simple, especially with the newer low-lag Game Mode of Creator's Update)

Other readers, any errors in this diagram?

Would you like to give jorimt permission to use (recreate) this diagram in one of his GSYNC-101 Series articles?
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 » 05 May 2017, 09:59

RealNC wrote:GeDoSaTo does this:

http://blog.metaclassofnil.com/?p=715

It only works for DX9 games.
Fantastic, it's already done. Like minds thinks alike!

Predictive frame capping. Intentional delays, called "predictive waiting", to reduce lag.

Diagram from that page:
fps_capping.png
fps_capping.png (19.17 KiB) Viewed 5864 times
In theory, graphics drivers can be made to do this.

NVIDIA already does frametime prediction for many things -- e.g. microstutter reduction for SLI, variable overdrive for GSYNC, etc. In theory, that logic can be borrowed to create a low-latency VSYNC ON, but I suppose it could hurt their GSYNC monitor sales...

So, third party it is. Can we do this again for modern games to have the world's lowest-lag-possible VSYNC ON? It would be great for ULMB-lovers, LightBoost-lovers, etc -- since strobe modes look better with synchronized framerates. Maybe even possible via an extra layer, filter driver, or other third party utility that stands in front of the graphics drivers to insert forced delays.
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 » 05 May 2017, 10:39

<DREAMING>

P.S. I think we need a microstutter calculator/analyzer now.

Everything. All sources of microstutter. VSYNC OFF, Fast Sync, VRR, render times, mouse microstutter, etc.

Frame render time variances too, but not only that -- but also adds on microstutter calculations on top, above-and-beyond. Hugely varying frametimes can defeat the stutter-reduction abilities of GSYNC, because the calculated gameworld at the beginning of render jitters heavily out-of-sync with the render-finish times. Basically, varying times between input reads & pixels seen by eyes.

Microstutter converts to motion blur when microstutter vibrates beyond flicker fusion threshold.
As you can see on http://www.testufo.com/framerates#count=5 on a 240hz monitor,

Also, low-framerates still look like stutter, no matter how perfect the frametimes are.

As we already know now today:
For 960 pixels/second perfect-frametime motion (TestUFO):
  • 15fps -- looks like regular stutter.
    64 pixal amplitude (stutter width)
  • 30fps -- looks likes regular stutter.
    32 pixel amplitude (stutter width)
  • 60fps -- begins to look like blur. Sensitive eyes still see this as stutter. Human dependant.
    16 pixel amplitude
  • 120fps -- looks like motion blur.
    8 pixel amplitude (blur width)
  • 240fps -- looks like motion blur.
    4 pixel amplitude (blur width)
(Assumptions: GtG/pixel response doesn't add to it. For 1ms TN monitors, GtG smearing/blur/ghosting are insignificant enough that the "half amplitude at double framerate" is extremely obvious at http://www.testufo.com/framerates#count=5

However, imperfect frametimes will often expand the width (amplitude) of the blurring, or create lower harmonic frequencies that are visible (e.g. 243fps @ 240Hz will show 3 stutters per second that may become visible again through the motion blur). In fact, our eyes can still see TestUFO do a single stutter when it suddenly goes down to 239fps instead of 240fps.

I've got enough understanding of microstutter physics to know how to mathematically analyze this (ignoring GtG limits, which is getting easier in the era of TN panels and OLED displays) but there's not enough software hooks to be able to (yet) accurately measure the microstutter of ALL sources and mathematically combine it into one microstutter benchmark number.

And heck, while we're at it -- mouse pollrate slewing effects (e.g. 5Hz lag yo-yoing) caused by 125Hz mouse on a 120Hz display. (Just because: framerate limiters aren't always in perfect sync with mouse pollrate, creating another 'tiny' microstutter error factor -- as much as 1-2 pixels of motion blurring added in LightBoost mode during left/right turns via mouse which often usually looks less fluid in LightBoost mode (even with perfect VSYNC ON) than keyboard strafe left/right) -- even at 1000Hz. (See Blur Busters Mouse Guide -- this is why we advocate the need for accurate 2000Hz poll rate during strobed/gsync mode -- as it can remove an additional few pixels of microstutter-induced motion blurring on high-Hz monitors -- assuming motion blur was the numero uno target).

And yes, the microstutter caused by slewing effects from a framerate cap set slightly below monitor refresh rate (in situations where it does not stabilize to a stable fix non-slewing lag lag) -- like Row #5 of chiaisthewei's diagram on this thread page.

Some tools exists for specific pieces of the puzzle. But I'd LOVE to see a tool that does the WHOLE-CHAIN microstutter analysis (mouse, display, game engine, input read timing to render timing, framerate-refreshrate asymmetries, etc)... This is quite important for VR which needs darn near perfect frametime delivery (zero-stutter), and I'm sure the VR industry already got tools. But we need a tool for regular FPS gaming.

</DREAMING>
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!

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

Re: NV DB Vsync + RTSS limit

Post by chiaisthewei » 05 May 2017, 10:41

Chief Blur Buster wrote:
chiaisthewei wrote:Image
Fantastic illustration!

I believe it looks mostly correct -- except for some clarifications.
--> "Vsync On No Cap" is really "Fast Sync" or a form of triple buffering (the low-lag kind), and F-numbers should be shifted 1-left. (I think).
--> "VSYNC ON" capped to refresh rate, is regular "VSYNC ON" -- it's self-capping. Pre-capped. API's with VSYNC ON waits to flip before returning to game.
--> First row really should be called "Default VSYNC OFF Behaviour" (or something like that)
--> Fourth row really should be called "Default VSYNC ON Behaviour" (or something like that)
--> First and Fourth rows should probably become First & Second Rows, because they're the most common settings.
--> VSYNC ON can vary quite a lot. I've seen slightly lower-lag VSYNC ON occur (F-numbers shifted 1 left) and higher-lag VSYNC ON occur (F-numbers shifted 1 or 2 right -- especially with higher "Queue Depth" numbers)
--> Second row is the least accurate, but may be occuring with Borderless Windowed + Compositing + VSYNC OFF. (compositing converts VSYNC OFF to VSYNC ON look).

Other than terminology clarifications, and row #2, your graph looks correct.

Also, "Fast Sync" in full screen is similar behavior to: Borderless Windowed Mode + Windows Compositing + VSYNC OFF (which can have similar tearing-free "Fast Sync" behavior) ... However, there can be extra lag caused by compositing overhead which shifts all the F-numbers 1 refresh cycle forward (though it may not be this simple, especially with the newer low-lag Game Mode of Creator's Update)

Other readers, any errors in this diagram?

Would you like to give jorimt permission to use (recreate) this diagram in one of his GSYNC-101 Series articles?
Yeah that's no problem, I actually drew it from various illustrations from people in this forum anyway, because I wanted a clear idea. I don't think it's entirely correct based off comments by sparky and you.

Also yeah terminology - what I meant in the illustration by "cap" is capping by framerate limiter like in-game fps_max or RTSS. I can clean it up, add some notes, and post the source and image here again :)

It seems like the "best" overall solution is simply variable refresh rate since that solves rendering queues, variable frame rates which is a lot likelier than stable frame rates, and smoothness of motion. But of course, that involves buying a new monitor and/or graphics card for many people who have existing systems.

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, 10:57

chiaisthewei wrote:It seems like the "best" overall solution is simply variable refresh rate since that solves rendering queues, variable frame rates which is a lot likelier than stable frame rates, and smoothness of motion. But of course, that involves buying a new monitor and/or graphics card for many people who have existing systems.
That said, variable refresh rates and strobing (Motion Blur Reduction / ULMB / LightBoost) aren't always easy to be done simultaneously.

They are working on that, but flicker frequencies are a problem at below ~75-100Hz. Things flicker too much at lower frequencies -- we hated 50Hz and 60Hz CRTs because of that.

I think strobed VRR will be far more pratical during 100Hz-480Hz VRR ranges, once 480Hz rolling-scan OLEDs arrive with adjustable-height rolling scans (to adjust impulse width on the fly as refresh rate varies). Low persistence VRR -- with zero motion blur! And avoiding the varying-motion-blur effect of regular lower-Hz VRR.
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!

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

Re: NV DB Vsync + RTSS limit

Post by Sparky » 05 May 2017, 14:53

RealNC wrote:GeDoSaTo does this:

http://blog.metaclassofnil.com/?p=715

It only works for DX9 games.
Does that work properly now?

http://forums.blurbusters.com/viewtopic.php?f=10&t=2168

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, 16:10

No idea. Never used it. I just know it exists and that it does predictive frame capping.
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.

Post Reply