Blur Busters Forums

Sparky wrote:

lukeman3000 wrote:

jorimt wrote:@lukeman3000, G-SYNC + Fast Sync acts exactly like G-SYNC + v-sync on within the G-SYNC range (inside max refresh rate of display). There is only a difference between those scenarios when you exceed the G-SYNC range, at which point (with G-SYNC + Fast Sync + no fps limiter), G-SYNC disables, and Fast Sync enables.

You can see the chart here, if you haven't already (Fast Sync input latency numbers will be updated once I'm finished with my input latency re-tests, which are currently in progress):
http://www.blurbusters.com/gsync/gsync101-range/

For a variety of reasons, there is zero benefit to using G-SYNC with Fast Sync in my opinion.

Furthermore, if I'm using an FPS limiter to stay below my monitor's refresh rate, then it really doesn't matter whether or not I have V-Sync or Fast selected, because I should always stay within G-Sync range, which is preferable... right?

Also, how many FPS below the monitor's refresh rate do you recommend to cap at? And is RTSS still recommended, or is there a better option?

There *should* be no difference in that situation, but the outliers in frame time could introduce one. Say you have a normal frame, a long frame and a short frame in that sequence, both will display the normal frame twice, and fast sync will drop the long frame in favor of the short one, while v-sync will display all 3. So the median latency is identical, fast sync recovers from hitches faster, but v-sync recovers from hitches more smoothly.


In game cap is always preferable if it's available, other than that, RTSS is fine.

Ok. How low below my monitor's refresh rate of 165 Hz should I set the frame rate cap?

Also, what happens if I have an in-game cap and RTSS active at the same time? Which one takes priority? And does having RTSS active in this case hurt me in any way?

lukeman3000 wrote:

Sparky wrote:

lukeman3000 wrote:

jorimt wrote:@lukeman3000, G-SYNC + Fast Sync acts exactly like G-SYNC + v-sync on within the G-SYNC range (inside max refresh rate of display). There is only a difference between those scenarios when you exceed the G-SYNC range, at which point (with G-SYNC + Fast Sync + no fps limiter), G-SYNC disables, and Fast Sync enables.

You can see the chart here, if you haven't already (Fast Sync input latency numbers will be updated once I'm finished with my input latency re-tests, which are currently in progress):
http://www.blurbusters.com/gsync/gsync101-range/

For a variety of reasons, there is zero benefit to using G-SYNC with Fast Sync in my opinion.

Furthermore, if I'm using an FPS limiter to stay below my monitor's refresh rate, then it really doesn't matter whether or not I have V-Sync or Fast selected, because I should always stay within G-Sync range, which is preferable... right?

Also, how many FPS below the monitor's refresh rate do you recommend to cap at? And is RTSS still recommended, or is there a better option?

There *should* be no difference in that situation, but the outliers in frame time could introduce one. Say you have a normal frame, a long frame and a short frame in that sequence, both will display the normal frame twice, and fast sync will drop the long frame in favor of the short one, while v-sync will display all 3. So the median latency is identical, fast sync recovers from hitches faster, but v-sync recovers from hitches more smoothly.


In game cap is always preferable if it's available, other than that, RTSS is fine.

Ok. How low below my monitor's refresh rate of 165 Hz should I set the frame rate cap?

Also, what happens if I have an in-game cap and RTSS active at the same time? Which one takes priority? And does having RTSS active in this case hurt me in any way?

5fps below refresh rate should be good, in theory anything below the refresh rate is fine, but hitches can throw off a framerate limiter. 5fps below refresh rate lets it recover from a 1 frame overshoot within 200ms.

Whichever is set lower takes priorty, and RTSS will have 1 frame more input lag than an in game cap. Maybe set RTSS global limit at 160 and in game limits at 155 for the games that support it. Should be a very good setup that you don't have to mess with when switching games.

Sparky wrote:Whichever is set lower takes priorty, and RTSS will have 1 frame more input lag than an in game cap. Maybe set RTSS global limit at 160 and in game limits at 155 for the games that support it. Should be a very good setup that you don't have to mess with when switching games.

A staged framerate limiter is an excellent idea.
- Setting the lower-lag internal framerate limiters (in-game) to a slightly lower value
- Setting the higher-lag external framerate limiter (RTSS/NVCP/etc) to a slightly higher value
Both values lower than the GSYNC (or FreeSync) maximum refresh rate, to prevent the lag-increase effect of suddenly hitting the monitor's maximum refresh rate.

It appears that the closer to the game, the better.

[Lowest lag]
- In-game frame rate limiter
- App/Driver frame rate limiter
- Monitor frame rate limiter (aka hitting max Hz during GSYNC).
[Highest Lag]

Sparky wrote:5fps below refresh rate should be good, in theory anything below the refresh rate is fine, but hitches can throw off a framerate limiter. 5fps below refresh rate lets it recover from a 1 frame overshoot within 200ms.

I've been meaning to investigate this concept in more detail for a while.

What does one mean when one says "overshoot" in this context? The framerate limiter is only the limiting factor when the fps is high and the frametimes are low; a hitch would indicate a frametime spike, which actually plummets the fps and raises the frametime considerably, at which point the fps limiter wouldn't be a factor at all until the framerate recovers and exceeds the given fps limit, right?

jorimt wrote:

Sparky wrote:5fps below refresh rate should be good, in theory anything below the refresh rate is fine, but hitches can throw off a framerate limiter. 5fps below refresh rate lets it recover from a 1 frame overshoot within 200ms.

I've been meaning to investigate this concept in more detail for a while.

What does one mean when one says "overshoot" in this context? The framerate limiter is only the limiting factor when the fps is high and the frametimes are low; a hitch would indicate a frametime spike, which actually plummets the fps and raises the frametime considerably, at which point the fps limiter wouldn't be a factor at all until the framerate recovers and exceeds the given fps limit, right?

That's exactly what I mean by "overshoot". Framerate limiter sees framerate is too low, so it tries to correct, but because of the nature of the hitch, any correction is too much.

Not sure how to properly investigate it. To start with you'd have to be able to repeatably introduce framerate hitches of a known character, and see how the limit reacts to it. Ideally you get source code access to the framerate limiter, coupled with FCAT, so you can see exactly how much time the framerate limiter is impacting each frame.

Chief Blur Buster wrote:It appears that the closer to the game, the better.

Nah, it should actually be the closest possible to the max refresh. Otherwise it's gonna trigger even when not needed, and thus add one frame of lag.

You do NOT want the external limiter to trigger when using an in-game limiter, except as last resort only.

So on 165Hz, when using an in-game limiter of 150FPS, RTSS should still be set to something like 163FPS. The in-game limiter has room to "breathe" in this case without triggering RTSS as often.

I don't think it makes any difference, unless one framerate cap averages several frames and the other doesn't.

Sparky wrote:I don't think it makes any difference, unless one framerate cap averages several frames and the other doesn't.

Yes, that's the whole point. In-game cappers aren't always accurate. If they were, chaining RTSS on top would be useless.

Yes, a cascading frame rate limiter is only good if the lowest-lag limiter is sometimes inaccurate and lets spikes happen (creating single-frame tearlines that could have been prevented by a cascading framerate limiter)

Tests will be needed to see how effective a cascading framerate limiter is.

I imagine it is not needed when the in-game limiter is very accurate.

RealNC wrote:

Chief Blur Buster wrote:It appears that the closer to the game, the better.

Nah, it should actually be the closest possible to the max refresh. Otherwise it's gonna trigger even when not needed, and thus add one frame of lag.

You do NOT want the external limiter to trigger when using an in-game limiter, except as last resort only.

So on 165Hz, when using an in-game limiter of 150FPS, RTSS should still be set to something like 163FPS. The in-game limiter has room to "breathe" in this case without triggering RTSS as often.

Actually, you are probably right too.

I think Einsten is right too -- it is a frame of reference (perspective). The closer the buffer is to the game, the easier it is to potentially laglessly control the timing of frame delivery.

We've thus found out that ingame can be less than RTSS, and RTSS can be less than the monitor 'limiter' (max Hz forcing a wait VSYNC). When thought of this way, in this frame of reference, even if not always a hard-and-fast rule -- the closer the buffer is timed to the game, the more control there appears to have simultaneously low-lag AND accurate desired frame delivery time... the more likely the frame delivers jitterlessly (translates into avoiding stutter) down the chain to the pixels on screen without increasing lag (less need for buffering/delay down the chain after the earlier frame limiter).

When thought of this way, we get close to almost saying the same thing...