External framerate caps adds lag. Use in-game framerate cap.

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: External framerate caps adds lag. Use in-game framerate

Post by Chief Blur Buster » 01 Jun 2014, 01:08

RealNC wrote:What would be an internal cap, in your eyes?
Examples:
Quake Live -- its internal cap of 125fps (now 250fps)
Half Life -- fps_max command

For just-in-time VSYNC, it's kinda both (internal/external interaction), where you're doing internal control to reduce external delay, by waiting internally until the last minute before an external VSYNC event (refresh cycles are non-delayable events except on GSYNC monitors).
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!

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: External framerate caps adds lag. Use in-game framerate

Post by flood » 01 Jun 2014, 02:30

yup, anything that depends on sleep (usleep/Sleep/whatever) to limit framerate rather than on having swapbuffers block. it's not a precise definition but anyway that isn't important. the bottom line is that the best possible game experience is achieved by gsync + an internal cap.

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

Re: External framerate caps adds lag. Use in-game framerate

Post by RealNC » 01 Jun 2014, 02:58

Wouldn't it be nice if the hardware was able to tell you exactly how much time the rendering is going to take before you actually do it? I could imagine "adaptive detail" algorithms would be possible with that, to keep the framerate high at all times.
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.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: External framerate caps adds lag. Use in-game framerate

Post by flood » 01 Jun 2014, 19:59

yup that's a nice idea but given the amount of operations done in rendering, an accurate algorithm that profiles the operations could significantly affect performance. I suppose you could write heuristic algorithms to predict the frame render time based on some properties of the scene.


User avatar
Arulan
Posts: 7
Joined: 22 Jul 2014, 12:01

Re: External framerate caps adds lag. Use in-game framerate

Post by Arulan » 22 Jul 2014, 12:21

I'm curious if anyone has done extensive testing with RivaTuner Statistics Server's framerate limiter. I've tried several framerate limiters in the past and most of them either do not help to eliminate display judder (when capped at fps=Hz or whole divisible ratios), introduce noticeable input lag, or do not properly maintain the cap. RTSS is the exception in my testing.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: External framerate caps adds lag. Use in-game framerate

Post by flood » 22 Jul 2014, 20:56

Arulan wrote:I'm curious if anyone has done extensive testing with RivaTuner Statistics Server's framerate limiter. I've tried several framerate limiters in the past and most of them either do not help to eliminate display judder (when capped at fps=Hz or whole divisible ratios), introduce noticeable input lag, or do not properly maintain the cap. RTSS is the exception in my testing.
sounds interesting. it should be reasonably easy to determine in which part of the pipeline the framerate is capped, by printing the time deltas between various parts of the main loop

stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: External framerate caps adds lag. Use in-game framerate

Post by stirner » 07 Aug 2014, 05:08

Up until now I had been using an external framerate limiter because FRAPS shows drastic improvements in frame frequency stability as opposed to the Source engine's internal fps_max cvar: i.imgur.com/Bb4nGOf.png vs. i.imgur.com/xVmoO3D.png

Could you put into more straight-forward terms what you think external framerate limiters are doing that internal ones are not (where are you getting that information from?).
From what I gathered in your original post, external caps supposedly render a frame and then wait with swapping buffers to make that frame available to the monitor for Xms depending on framerate, while internal capping functions by first gathering input during the rendering interval, then have the GPU render the frame and switch buffers right before the interval ends.

At 100fps capped this would mean -

with an external cap:

0ms: initiate rendering of frame #1
Xms: finish rendering
10ms: switch buffers
10ms: initiate rendering of frame #2
10+xms: finish rendering
20ms: switch buffers
20ms: initiate rendering of frame #3
etc., input data being gathered throughout the process and grabbed every 10ms

with an internal cap:

0ms-?ms: gather input data
?ms: initiate rendering of frame #1
?ms: finish rendering
10ms: switch buffers
10-?ms: gather input data
?ms: initiate rendering of frame #2
?ms: finish rendering
20ms: switch buffers
etc.

This would leave me with a few questions:

When exactly does the internal code initiate rendering? The GPU naturally needs time to render a frame, varying amounts of time at that - how does the code decide that it is time for the rendering process to be initiated in order for the rendering interval to be maintained? I mean, the game cannot know how long the GPU will need to render a certain frame.

If the GPU really did delay swapping of buffers instead of delaying the rendering with an external cap, then the simulation would have to look extremely smooth, less microstutter-y and frame tearing should be mostly unnoticeable as long as rendering finishes within the capped interval, because frames are presented to the user at precisely the same frequency. But in my experience that is not necessarily the case. So I think the GPU does delay rendering and not buffer switching in order to maintain a limt.

Swapping or "presentation of frame" delayed @ 100fps:
0ms: initiate rendering of frame #1
e. g. 2ms: finish rendering
10ms: switch buffers
10ms: initiate rendering of frame #2
e. g. 15ms: finish rendering
20ms: switch buffers
You can see that even though there is variance to the time needed to render the frames (2ms for frame #1, 5ms for frame #2), they are made available for the screen and therefore presented to the user at a constant frequency (10ms).

Rendering being delayed @ 100fps:
0ms: initiate rendering of frame #1
e. g. 2ms: finish rendering
2ms: switch buffers
10ms: initiate rendering of frame #2
e. g. 15ms: finish rendering
15ms: switch buffers
20ms: initiate rendering of frame #3
Here frames are made available to the screen and therefore presented to the user at the rate they are being rendered, which varies depending on time needed for rendering, but is made to not exceed 100 rendering processes per second.

I can see how grabbing input data and then waiting with buffer swapping for the remainder of the time needed to sustain the capped interval would cause perceived input lag, but I'm not sure that's how external limiters operate. All of this is based on empirical observations more so than understanding of the code, the general 3D architecture and their interplay with the GPU, so please do bear with me if I have made any outlandish assumptions.

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

Re: External framerate caps adds lag. Use in-game framerate

Post by Chief Blur Buster » 08 Aug 2014, 13:36

stirner wrote:Up until now I had been using an external framerate limiter because FRAPS shows drastic improvements in frame frequency stability as opposed to the Source engine's internal fps_max cvar: i.imgur.com/Bb4nGOf.png vs. i.imgur.com/xVmoO3D.png
This is normal: External framerate capping is superior if your goal is motion fluidity. For example, VSYNC ON double-buffered, combined with a powerful GPU, can lead to ultrasmooth motion that looks wonderful with strobing.

However, best possible frame frequency stability isn't equal to best possible input lag.
stirner wrote:with an internal cap:

0ms-?ms: gather input data
?ms: initiate rendering of frame #1
?ms: finish rendering
10ms: switch buffers
10-?ms: gather input data
?ms: initiate rendering of frame #2
?ms: finish rendering
20ms: switch buffers
etc.
This is incorrect during VSYNC OFF. The switch buffers often happens virtually instantly upon finishing rendering. The tearline occurs at the raster location where the screen is "still scanning". This is what happens with either VSYNC OFF or GSYNC:

0ms-?ms: gather input data
?ms: initiate rendering of frame #1
?ms: finish rendering AND switch buffers
10-?ms: gather input data
?ms: initiate rendering of frame #2
?ms: finish rendering AND switch buffers
20-?ms: gather input data
?ms: initiate rendering of frame #3
?ms: finish rendering AND switch buffers

The image data gets onto the cable within microseconds of the buffer switch. It does not occur at grandular frame refresh intervals. There is a concept known as the "horizontal scanrate" (number of scanlines drawn per second), which carried over from the old CRT days. Data is transmitted at a finite speed over the cable. At 120Hz 1080p, the horizontal scanrate is typically about 135KHz (as seen in Custom Resolution Utilities), which is 135,000 rows of pixels per second. One row of pixels get pushed into the video cable in 1/135000th of a second. You can do a buffer flip at any time during a 1/135000th second granularity, rather than a 1/120th sec granularity. This is how tearlines occur, they are essentially refresh-cycle "splices" between an old refresh and a new refresh, caused by a buffer flip in the middle of a refresh cycle!
stirner wrote:When exactly does the internal code initiate rendering?
Game engine dependant. Some of them do just-in-time rendering techniques, while others just simply begin rendering immediately after the previous frame.
stirner wrote:The GPU naturally needs time to render a frame, varying amounts of time at that - how does the code decide that it is time for the rendering process to be initiated in order for the rendering interval to be maintained? I mean, the game cannot know how long the GPU will need to render a certain frame.
This is true, and a common cause of stutter. Fortunately, adjacent frames usually have very similiar scene complexities (you're usually viewing in the same direction or almost the same direction), so frametimes are usually similar, but it varies by game engine. If you hate this, just simply use external framerate capping to smooth things out, if smoother is more important than less lag. Those are often two opposing goals.
stirner wrote:If the GPU really did delay swapping of buffers instead of delaying the rendering with an external cap, then the simulation would have to look extremely smooth, less microstutter-y and frame tearing should be mostly unnoticeable as long as rendering finishes within the capped interval
Again, smoothness (consistent frame delivery) goal is different from low lag goal. They can be sometimes mutually opposing goals as a trade-off.

If you want perfect fluidity on a non-GSYNC monitor, and don't care about lag, use the following:
1. VSYNC ON (external capping)
2. Double buffering, not triple buffering
3. Gaming mouse with good 1000Hz mode
4. Powerful enough GPU
5. Frame rate exactly matching refresh rate.
6. Adjust detail down until framerate stays capped out without dropping.
7. Run game engines that are capable of capping out at frame rates matching refresh rate.

Motion can look really beautiful (Sega arcade or Nintendo 8-bit platformer style smoothness of scrolling) when you combine #1-7 simultaneously. It especially looks really good with motion-blur-reducing strobe-backlight technologies (LightBoost, ULMB, Turbo240, and BENQ Blur Reduction).

I actually use VSYNC ON for solo gameplay when lag is not critical since motion on strobe backlights (LightBoost/ULMB) looks nicer with VSYNC ON.
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
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: External framerate caps adds lag. Use in-game framerate

Post by RealNC » 08 Aug 2014, 15:05

Chief Blur Buster wrote:This is normal: External framerate capping is superior if your goal is motion fluidity. For example, VSYNC ON double-buffered, combined with a powerful GPU, can lead to ultrasmooth motion that looks wonderful with strobing.
I'd wish to point out again that double-buffering is worse than triple-buffering for fluidity. Again: the kind of TP you're talking about is not used anymore.
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