John Carmack has a tweet:
"Triple buffering adds latency and jitter; it should be avoided. The Answer is non-isochronous display updates."
Can anyone explain what he meant by adds latency and jitter?
\$\begingroup\$
\$\endgroup\$
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
I have an idea of where the jittering comes from with vSync and triple buffering. The easiest way to show this is visually.
The first example would be 30fps with a 60hz refresh rate vSynced with Double buffering. The pipes are new frames and periods are duplicated frames.
|.|.|.|.|.|.|.|.|.
This gives an even ~33ms between each new frame, which makes it appear smooth (for 30 fps anyway). You can see how fitting 60fps into the same situation fits perfectly into the timing interval, allowing for a new frame every refresh.
Now, lets see how it would look running 45fps at a 60hz refresh rate vSynced with Triple Buffering:
|||.|||.|||.|||.|||.
You can see here that there is an uneven interval between frames. In this case, the frame times are 16,16,16,33,16,16,16,33. Since the monitor only updates once every ~16ms, if a new frame isn't ready for a particular update, it still has to wait a whole additional ~16ms, even if its ready 1-2ms after the previous update.
However, I think the whole TB situation is still debateable and depends on the situation. Personally, I'd rather see 55fps with no tearing with occasional dropped frames than to go all the way down to 30fps to get even frame timing.
As a side note, this is a good example of how a 120hz monitor can increase smoothness of a game running at ~45fps since there is a higher frequency of times that a new frame can be displayed to the screen.
\$\begingroup\$
\$\endgroup\$
5
It adds latency because you've got 3 buffers involved instead of 2, so it takes one more frame for your rendered image to get to the screen.
I have no idea what kind of "jitter" Carmack is talking about here, though.
EDIT
Maybe, just maybe, this could make sense in a highly variable framerate context: frames rendered with a given delta-time but displayed later with a different delta, resulting in a visible jitter?
answered Jul 5, 2012 at 9:57
-
1\$\begingroup\$ When John Carmack refers to triple buffering does that mean when all three buffers have images in them the earliest backbuffer is replaced with the new image or does that mean that mean rendering of the new image is blocked until one of the backbuffers is available? \$\endgroup\$ Commented Jul 5, 2012 at 20:21
-
\$\begingroup\$ Buffer #1 is being rendered into. #2 is being displayed. #3 is waiting for a good time to replace #2 on the display. The additional latency allows rendering to continue instead of pausing for the swap like a double buffered setup. If you're done rendering before the swap then yes, you'd get some jerking because of the pauses happening two frames behind the current real time. Summary: you're using a current time to smooth out a historical render, which can vary and make for small twitches. \$\endgroup\$ Commented Jul 6, 2012 at 4:05
-
\$\begingroup\$ @PatrickHughes: Your explanation of why there is jerking doesn't make sense. \$\endgroup\$ Commented Jul 6, 2012 at 7:48
-
\$\begingroup\$ If you measure your interval by the previous flip, which was based on rendering from two frames ago, and then use that interval to calculate data in the current frame you're always going to be lagging the real interval by one frame. If your frames vary in time by any amount this will cause a following behavior where the game calculations don't match what will be displayed from those calculations.\ \$\endgroup\$ Commented Jul 6, 2012 at 17:53
-
\$\begingroup\$ Why measure your interval from the previous flip instead of the previous frame? Every new frame usually uses the timing from the previous frame for any time-based calculations like acceleration, etc., and it shouldn't matter, whether that frame was already displayed on screen or not. \$\endgroup\$– MarioCommented Oct 28, 2012 at 23:22