Blur Buster's G-SYNC 101 Series Discussion

Talk about NVIDIA G-SYNC, a variable refresh rate (VRR) technology. G-SYNC eliminates stutters, tearing, and reduces input lag.

Blur Buster's G-SYNC 101 Series Discussion

Postby jorimt » 19 Jun 2017, 08:54

This is the official discussion topic for Blur Buster's 4-part "G-SYNC 101" series featured on blurbusters.com:
http://www.blurbusters.com/gsync/gsync101/

Image

It is a continuation of my now archived original "G-Sync 101 w/Chart (WIP)" topic here:
viewtopic.php?f=5&t=3073

Image

I welcome further input, questions, and discussion regarding the G-SYNC 101 series, or G-SYNC functionality in general...
Blur Busters Contributor - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
jorimt
 
Posts: 305
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby jorimt » 19 Jun 2017, 08:55

viewtopic.php?f=5&t=3073&start=250#p26419
RealNC wrote:The input lag reduction appears with Fast Sync + v1 limiter cap. That is true for both G-Sync on and off (just like RTSS.) Which is indeed weird and doesn't seem to make much sense. Since I'm capping using a severe limit (23FPS), there's no chance I'm exceeding the G-Sync range and thus fast sync never kicks in. And yet, selecting fast sync is the only way I get the same "up to 1 frame" input lag as I do with RTSS.

So to clarify: new nvidia limiter + fast sync = RTSS + any sync. For your test, that means: nvidia limiter + g-sync + fast sync = RTSS + g-sync + vsync on.

viewtopic.php?f=5&t=3073&start=250#p26420
jorimt wrote:Okay, gotcha.

After I'm done with the main tests, I'll update the driver and inspector and do a quick G-SYNC + Fast Sync + v1 FPS limit at a single refresh rate with the new setting and see what I get.

As promised, I am posting the results of G-SYNC + Fast Sync + Nvidia Inspector FPS Limit, using the new “Frame Rate Limiter Mode('s)” “Limiter V2 – Force Off” option, available as of Nvidia Profile Inspector version 2.1.3.6 and Nvidia driver branch R381 or later, which claims to reduce input latency:

Image

If you've already read my article, you'll know that G-SYNC + Fast Sync behaves like G-SYNC + V-SYNC anywhere below 138 FPS at 144Hz. With G-SYNC, the standard v1 and v2 limiters add more latency to it than they do to standalone V-SYNC, for whatever reason (perhaps the clashing of frame pacing behaviors between the two).

The new override mode does seem to reduce the input latency by 1 frame or so. What it does to standalone V-SYNC, I'd have to test.

I didn't include any of this in the final results, as it could simply be a temporary driver quirk that could change or disappear in future releases. We'll give it some time, and if it remains, I may revisit it later on.

Regardless, I'd still recommend RTSS over Nvidia Inspector for G-SYNC if an in-game limiter isn't available.
Blur Busters Contributor - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
jorimt
 
Posts: 305
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby RealNC » 19 Jun 2017, 09:57

Fantastic and congratulations on finishing the project!

One thing not mentioned is that the behavior when the frame rate cap is not reached (capping to 142FPS but the game can only reach 135FPS for example) heavily depends on what "max pre-rendered frames" is set to. CS:GO and OW use 1 by default, so input lag should only increase by at most 1 frame. But in other games that use the default of 3, input lag will be increased by a lot more.

The results are only valid IF the frame rate cap is actually reached by the game. If someone caps to 142FPS on a 144Hz monitor, following the article to the letter, but his system isn't capable of 142FPS, input lag will go up disproportionately.

This is (IMO) a useful thing to note for people who look to get the lowest input lag possible, especially since it's counter-intuitive (lowering your FPS gives lower input lag.)
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
RealNC
 
Posts: 1112
Joined: 24 Dec 2013, 18:32

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby jorimt » 19 Jun 2017, 10:15

Thanks RealNC! It was nearly two months of steady work, but I believe it was well worth it.

I debated whether to include that section at all, and added it last minute to be thorough and avoid possible unnecessary follow-up questions on the omission of the MPR setting.

I primarily focused on only one aspect of the input latency chain, so a secondary effect such as MPR with such variable impact was neglected. I'd really have to do a dedicated MPR article one day to get to the bottom of it all.

And honestly, I don't know as much about the setting as you do, and am still processing your information. To be clear, does the behavior you describe occur only when you have an FPS limit in place and aren't hitting it, or does it also occur at any framerate below the refresh rate without an FPS limit applied and MPR set to anything other than "1"?
Blur Busters Contributor - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
jorimt
 
Posts: 305
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby RealNC » 19 Jun 2017, 10:54

jorimt wrote:To be clear, does the behavior you describe occur only when you have an FPS limit in place and aren't hitting it, or does it also occur at any framerate below the refresh rate without an FPS limit applied and MPR set to anything other than "1"?

It occurs with and without a frame limiter. If a game renders at, say 95FPS, input lag is the same regardless of whether you limit FPS to 141 or not at all.

This is also a bit counter-intuitive to the "RTSS adds up to 1 frame of latency" statement. In this scenario, RTSS will REDUCE input lag, not INCREASE it if you cap the game to 94FPS.

However, this should only be a side-note, as it does have nothing to do with g-sync (which is the article's subject matter.) It is however, a very useful fact for people who want the most lag-free experience they can get. Even if you don't use g-sync and play with vsync OFF, RTSS will reduce input lag by making sure the game gets frame capped.

It's weird, I know, but it's what seems to happen with the majority of single player games. Games tuned for latency (like CS:GO and OW) don't seem to follow this pattern. Games like Witcher 3, Fallout (all of them), Deux EX, you name it, are exhibiting this behavior.

The technical details behind this seem to be related to single-player games not trying to keep any kind of synchronization between CPU and GPU. The "pre-render frames" mechanism is inherently an asynchronous concept, and thus render or frame presentation or buffer flip operations seem to get queued even with vsync off. When using frame limiting, even with RTSS, it would seem that things become synchronous; only one operation is in the queue, which basically means it's synchronous; the game is blocked from doing anything further until the single queued operation is completed.

Someone with more experience with the D3D or GL APIs would most probably have some insight to give here.

I also have to wonder if a frame limiter like RTSS could be modified in such a way that it behaves as if the frame cap is always reached, regardless of what you set it to. For example by blocking at the Present() function call (D3D) regardless of whether the frame time is lower than the target time or not. I looked for any open source frame limiters out there that I could use to experiment with this, but there don't seem to be any :|
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
RealNC
 
Posts: 1112
Joined: 24 Dec 2013, 18:32

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby RealNC » 19 Jun 2017, 11:47

I forgot to mention how to test this. I think I did somewhere in an old post, but here it is in case I didn't. (We'll use Witcher 3, but any other game should work, including CS:GO and OW.)

  • Start RTSS + Afterburner (for the OSD). Set the cap to 140.
  • In Profile Inspector, in the game's profile, set MPRF to 8
  • In NVCP, force vsync OFF, g-sync OFF. (Just to demonstrate that syncing has got nothing to do with all this.)
  • Make sure the in-game frame limiter is disabled (set to "Unlimited" in the Video->Graphics options.)
  • Disable the hardware cursor (Video->Graphics->Hardware cursor OFF.)
  • Crank-up the visuals to ultra and then some.
  • Find a nice spot that gives you a low-ish frame rate. In my case, 70-80FPS.
  • Press escape. This freezes the scene and stabilizes FPS. In my case, 76.4FPS.
  • Move the mouse around. HUGE input lag. (No understatement here. It's a freakin' boat due to MPRF 8.)
  • Alt+tab to RTSS, set a cap of 76FPS (that's just 0.4 lower than the game is currently running at.)
  • Alt+tab back to the game. The OSD now tells you 76.0FPS. Move the mouse around: it's instant. No lag.

It's not just the mouse, obviously. If you play the game you'll see that without a cap, input lag is huge without RTSS. As soon as you cap the frame rate, and IF the game hits that cap, input lag is obliterated.

(In other games the mouse cursor WON'T do for the test, as most games use hardware cursors. In other games, you need to use in-game mouse-look for the latency test, not mouse cursor movement.)

What I cannot test, however (only you can, hint hint :-P), is whether MPRF 1 when not hitting the cap gives as low input lag as MPRF 1 + cap. If not, meaning MPRF 1 (the best that can be done) has higher input lag than capped frame rate, then that's kind of huge news for people who prefer the lowest latency possible, even it means giving up some extra FPS. And it means RTSS (and other cappers) have a big opportunity here to introduce a latency reducing mode that knows how to make the game always hit a cap, (a new "dynamic/adaptive" cap; probably a fixed frame time offset regardless of current FPS (again, an open source limiter would have allowed me to do this myself, but, well.)
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
RealNC
 
Posts: 1112
Joined: 24 Dec 2013, 18:32

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby jorimt » 19 Jun 2017, 11:53

I see. Good info.

I may do some more tests and create a separate topic about that in the Input Lag sub-forum sometime in the future. No ETA, but definitely a possibility. It's worth investigation.

That said, until more is known about the behavior, my suggestion featured in the article still stands for simplicity's sake (it's basically performance stability vs. possible input latency decrease)...for now ;)
Blur Busters Contributor - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
jorimt
 
Posts: 305
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby RealNC » 19 Jun 2017, 12:14

A tip for g-sync windowed mode: Instead of restarting, if the setting doesn't seem to apply, you can kill dwm.exe in the task manager. It will restart automatically and should get g-synced after that.
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
RealNC
 
Posts: 1112
Joined: 24 Dec 2013, 18:32

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby jorimt » 19 Jun 2017, 12:27

Yeah, it happened twice to me in testing, so I thought I'd note it down to be safer than sorry, because it can happen. Good tip though.

It can also happen if you have a game launcher open while applying the G-SYNC setting; sometimes the game launcher is attached to the game exe process, and when the G-SYNC setting is switched from fullscreen to borderless/windowed mode, the change may not be recognized until a full game restart.
Blur Busters Contributor - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
jorimt
 
Posts: 305
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby Chief Blur Buster » 19 Jun 2017, 12:32

BTW, we are planning to have a "Ultra-Low Lag VSYNC ON HOWTO" too later this year.

While I'm probably going to write that one, this may be written by another Blur Busters writer (jorimt, spacediver, or others) who steps forward on this subject matter (If you're a sufficiently "Blur Busters Science Savvy" with freelance-writing experience and lots of experience with reducing lag of VSYNC ON, I want to hear from you, squad[at]blurbusters.com ...)

For those very fast games that you want to run stutterfree/tearingfree at maximum refresh rate -- Capped GSYNC/Capped FreeSync produce the ultimate low-lag "VSYNC ON" look -- the fluidity of VSYNC ON with none of the VSYNC ON buffer lag.

But not everyone has GSYNC monitors, so more advanced frame-capping tricks (RTSS, NVInspector, GeDoSaTo, etc) -- and ways to prevent the yo-yoing "sawtooth-latency" effects -- will be needed. On this note, we'll also be researching the "Ultra-Low-Lag VSYNC ON" subject matter throughout this year for future articles and HOWTOs! This should be of very big help to strobe-backlight users, who are often stuck using VSYNC ON.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3309
Joined: 05 Dec 2013, 15:44

Next

Return to G-SYNC

Who is online

Users browsing this forum: Bing [Bot] and 3 guests