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. List of G-SYNC Monitors.
User avatar
RealNC
Site Admin
Posts: 2826
Joined: 24 Dec 2013, 18:32
Contact:

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

Post by RealNC » 25 Jun 2017, 11:12

Sparky wrote:MPRF should never have an impact when your framerate is limited by an in game cap.
Yep, exactly. If you actually hit the cap, it should behave like "MPRF 0" (which isn't possible to actually set it to) regardless of what value it uses. It can be 1, it can be 8, doesn't matter. Once you hit the frame rate cap, it seems to behave like it's 0.

Keep in mind that many years ago, it was possible to set MPRF 0 in the nvidia driver, and it had a slight latency reduction compared to MPRF 1. I suspect hitting a frame cap has the same result as MPRF 0 had many years ago. (In non-ancient driver versions, setting it to 0 has no effect; it just treats it as 3 or default.)

Also, there's other things to account for. Like Sparky mentioned, maxing out the GPU seems to have a negative effect on latency. Which does make sense, since if you queue up more work than it can handle, that work piles up (and by the time it's processed, it's based on older player input.) Hitting a frame cap means the GPU always has some room left to "breathe".

I made a suggestion for RTSS to add a special frame limiting mode that does exactly this:

http://forums.guru3d.com/showthread.php ... ost5445352
TwitterSteamGitHubStack 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
jorimt
Posts: 827
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 25 Jun 2017, 11:19

Sparky wrote:MPRF should never have an impact when your framerate is limited by an in game cap.
Correct, that has always been my understanding, which is why RealNC's original proposition on the subject initially confused me. Again, I'd have to up the settings until sustained framerates naturally fall below the refresh rate to test his theory fully.
RealNC wrote:Yep, exactly. If you actually hit the cap, it should behave like "MPRF 0" (which isn't possible to actually set it to) regardless of what value it uses. It can be 1, it can be 8, doesn't matter. Once you hit the frame rate cap, it seems to behave like it's 0.
Then I assume I can practically test this if leave MPRF at default, force Overwatch to hover in sustained framerates below the refresh rate (e.g. in-game fps limiter not the limiting factor), and compare those numbers against the previous? Because I can do that now.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

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

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

Post by RealNC » 25 Jun 2017, 11:32

jorimt wrote:Then I assume I can practically test this if leave MPRF at default, force Overwatch to hover in sustained framerates below the refresh rate (e.g. in-game fps limiter not the limiting factor), and compare those numbers against the previous? Because I can do that now.
According to the theory, you should only see a small latency improvement in OW (perhaps even marginal.) Big latency improvements should only be had in games that are not doing any latency optimizations (the usual suspects here are always single-player games.)

In other words, this should not be as important in OW and CS:GO as it is in, say, Witcher 3, Fallout 4, those kinds of games.

With that said, it's not impossible that there could be a tangible latency difference even in OW between capped and uncapped, but it would be rather surprising. Depends on how "overworked" OW allows the GPU to be when it hits that 99% load.
TwitterSteamGitHubStack 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
jorimt
Posts: 827
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 25 Jun 2017, 11:35

I'd have to set the game to 150% internal res to naturally sustain framerates in the high 130s in my test scenario. Would being GPU limited (resolution) skew these results?
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

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

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

Post by RealNC » 25 Jun 2017, 12:03

I'd say quite the contrary. It's what we want tested. Uncapped FPS means you're exhausting available GPU time. The test can determine whether making sure GPU is not exhausted (by using a frame limiter) would have latency benefits.

Don't get confused with the VRAM bandwidth issue I mentioned in CS:GO's case. That is what could skew results, because when you hit a memory bandwidth bottleneck, you're neither GPU nor CPU limited. MSAA use bandwidth-hungry, and 8xMSAA would probably hit the memory bandwidth limit at 5K resolution. But this is not the case here.

(You usually know when you have a bandwidth bottleneck when your CPU and GPU usage is low, even though you're running uncapped frame rates.)
TwitterSteamGitHubStack 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
jorimt
Posts: 827
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 25 Jun 2017, 12:38

Well, that's...interesting.

Single runs again, 10 samples per on XB271HU at 144Hz, G-SYNC + V-SYNC enabled. All game setting maxed (but for reflections at "Medium"), Reduced Buffering enabled.

G-SYNC + V-SYNC + 141 FPS In-game Limit + MPRF Default:
MIN: 20
AVG: 23
MAX: 26

G-SYNC + V-SYNC + 141 FPS In-game Limit + MPRF "1":
MIN: 21
AVG: 24
MAX: 28

Then I set the in-game limiter to max of 300, and internal resolution to 150% to sustain framerate in the 130s without a framerate limiter...

G-SYNC + V-SYNC + mid to high 130s Uncapped + MPRF Default:
MIN: 35
AVG: 38
MAX: 41

G-SYNC + V-SYNC + mid to high 130s Uncapped + MPRF "1":
MIN: 37
AVG: 39
MAX: 41

I'm seeing a two frame increase...

I bet you if I tested RTSS capped 130-141, I'd see a one frame increase over in-game, and a one frame decrease over uncapped at the same framerate.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

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

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

Post by RealNC » 25 Jun 2017, 12:50

Thanks for doing the test!

Alright, it seems this works even with latency-optimized games then. I suspected the difference would be tiny, but it seems substantial.

So even OW benefits. It seems the engine pushes frames to the GPU even if the GPU cannot actually process any more frames and thus they need to wait. A two-frame increase could be explained by 1 frame being one of the buffers in a double-buffer scenario, the other frame due to MPRF 1. Maybe.

Now I wonder if the difference in non-optimized games would be even bigger than that. In Fallout 4 and Witcher 3 for example, the game falling below the cap, even with MPRF 1, has a latency difference that can actually be felt without the need to measure it.

I always made sure the games I play hit the cap (within reason), but now we have some actual data to back that up instead of placebo-prone "feels faster" experiments.

jorimt wrote:I bet you if I tested RTSS capped 130-141, I'd see a one frame increase over in-game, and a one frame decrease over uncapped at the same framerate.
Hm, I suspect that this might be a case where RTSS is closer to in-game limiter. Since FPS is so close to the limit the engine can even render at, the in-game limiter has less room to work with to reduce latency. RTSS might actually be within half a frame of difference compared to the in-game limiter.

In theory...
TwitterSteamGitHubStack 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
jorimt
Posts: 827
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 25 Jun 2017, 13:03

Apparently.

This is the reason I tested the way I did in the article; I did not want this issue or MPRF muddying the results, thus I made the in-game/external FPS caps the limiting factor, allowing isolation of sync-induced latency differences ONLY.

I could test with the Witcher 3 or Fallout 4, it would simply be difficult to find a spot that would allow for high contrast/horizontal movement for my strafe test method.

Needless to say, we seem to know two things about Overwatch now:

1. You should always ensure the in-game cap is the limiting factor for the framerate (this probably goes for any game).
2. MPRF "1" offers no reduction in input latency, at least with Reduced Buffering enabled.
RealNC wrote:Hm, I suspect that this might be a case where RTSS is closer to in-game limiter. Since FPS is so close to the limit the engine can even render at, the in-game limiter has less room to work with to reduce latency. RTSS might actually be within half a frame of difference compared to the in-game limiter.

In theory...
Seeing as MPRF "1" has no effect in Overwatch, doesn't this already tell us?

Image
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

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

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

Post by RealNC » 25 Jun 2017, 13:21

jorimt wrote:I could test with the Witcher 3 or Fallout 4, it would simply be difficult to find a spot that would allow for high contrast/horizontal movement for my strafe test method.
Strafing in these games is rather unpredictable. I would instead bind the mouse button to something that causes "camera" (viewport) movement. Not sure if that can be done. Maybe some trickery with Logitech Gaming Software rebinding... Will take a look when I get the chance and see if there's some trick you could use.
Seeing as MPRF "1" has no effect in Overwatch, doesn't this already tell us?
Nope. In your normal tests, the engine would normally be able to run at very high FPS if uncapped (400FPS+ I assume?) 400FPS means 2.5ms frame time. The cap is 142FPS. That's a frame time of 7ms. That means the in-game limiter has the potential to improve latency by up to 4.5ms (7 - 2.5).

If, on the other hand, the game would normally render at, say 150FPS and you cap to 142, the in-game limiter can improve latency only by up to 0.37ms. And these are the best-case values, even, and only achievable if the in-game limiter is 100% perfect. An no frame limiter is ever perfect.
TwitterSteamGitHubStack 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
jorimt
Posts: 827
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 25 Jun 2017, 13:25

RealNC wrote: Strafing in these games is rather unpredictable. I would instead bind the mouse button to something that causes "camera" (viewport) movement. Not sure if that can be done. Maybe some trickery with Logitech Gaming Software rebinding... Will take a look when I get the chance and see if there's some trick you could use.
I agree, and no, there isn't a fast and easy way to map look in those games (or it isn't possible at all). Would take some thinking.
RealNC wrote: Nope. In your normal tests, the engine would normally be able to run at very high FPS if uncapped (400FPS+ I assume?) 400FPS means 2.5ms frame render time. The cap is 142FPS. That's a frame time of 7ms. That means the in-game limiter has the potential to improve latency by up to 4.5ms (7 - 2.5).

If, on the other hand, the game would normally render at, say 150FPS and you cap to 142, the in-game limiter can improve latency only by up to 0.37ms.
Ah, then I'd have to test the in-game limiter up against RTSS with an upper 120 something FPS limit in the 150% resolution scenario where I can only sustain framerates in the 130s?

If so, I could do two more quick runs for confirmation.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

Post Reply