Jump to content

  • Log In with Google      Sign In   
  • Create Account

Negatives to Triple Buffering?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Satharis   Members   -  Reputation: 1264

Like
1Likes
Like

Posted 19 April 2014 - 11:38 PM

So both via Google and forum searching I've come up on wildly varying information about triple buffering and its impact, I'm trying to figure out what the legitimate information is.

I've read everything from it causing input lag(I don't see how it can) to even John Carmack tweeting that it is horrible and causes "lag and jitter" but again I don't see any reason why that would be. From an implementation standpoint it should always give higher FPS with vsync enabled(unless you're at the max fps for your refresh rate) correct?

I've also read conflicting information on whether D3D supports it, despite the fact dx11 and dxgi seem to be able to use more than one backbuffer and have different swap methods.

Guess my question is if there is any actual lag and what would cause that, along with how much of that is just misinformation.

Sponsor:

#2 Hodgman   Moderators   -  Reputation: 31851

Like
6Likes
Like

Posted 20 April 2014 - 12:37 AM

Why would it always give an FPS improvement?

All buffering causes input latency. With show-A/draw-B, show-B/draw-A (double buffering), they GPU is one frame behind the CPU, which is adding 16ms input lag (@60Hz).
Tripple buffering is show-A/draw-C, show-B/draw-A, show-C/draw-B, meaning the GPU is two frames behind the CPU, creating 33ms of latency (at 60Hz).

You can minimize this latency by disabling vsync, which means that the 'show/draw' blocks aren't rounded up to 16.6ms... But as you mentioned, this causes horrible jitter.
A constant 60fps/16.6ms per frame looks smooth. Having odd frames take 15ms and even frames take 1ms looks absolutely awful, movements aren't smooth, everything seems to be jerking back and forth as their perceived velocities are messed up by the varying presentation intervals...

As a thought experiment, think for a moment how our frame timers / delta time work in games - they're actually all wrong/hacky!!!
What most games do is - measure how much time has passed since last frame, advance all physics by this amount, draw all objects. The time it takes to do that update/draw work May or may not actually take "delta time" seconds to complete.
what we really want to be using is the time until THIS frame will be displayed, not the time taken by the PREVIOUS frame!
If It completes (and appears on the screen) in less time, then our game will appear to be running too fast. If it completes in more time, our game will appear to be in slow motion. However, the next frame will either slow down or speed up so that overall, game time stays in sync with real time.
Vsync is our friend here, because it tries to force all our frames to take the same amount of time (so previous time == current time, resulting in accurate predictions and smooth overall animation).
If you have a large number of buffered frames, and no vsync, then the length of time that each frame appears on the monitor for can be extremely variable. Some frames may be dropped altogether! This means our time predictions are very wrong (previous != current), so our game will alternate between too fast and too slow on a frame by frame basis, looking "jittery".

Tripple buffering with vsync is very nice for anti-jittering, as it allows you to even out your costs over a few frames. E.g. If you've got most frames taking 10ms, but one takes 20ms, the extra buffering can allow the GPU to still keep displaying one frame every 16ms. But as above, it results in an extra frames worth of latency between the user pressing a button and seeing the result, which is fine for many games, but not for a competitive FPS.

Another disadvantage is RAM usage. An extra (uncompressed) 1080p buffer is quite a decent number of megabytes!

Yes D3D is capable, you just create the extra backbuffers and use the appropriate present calls.

#3 Satharis   Members   -  Reputation: 1264

Like
0Likes
Like

Posted 20 April 2014 - 01:42 AM

Why would it always give an FPS improvement?

Because with vsync if you can't maintain 60 fps you end up missing every other blanking interval, thus your fps gets locked to half because if you say are drawing every 20ms then you'd miss the first interval, and have to wait till 33.2 to begin drawing, since the back buffer would be sitting there full at the 20ms mark waiting for the next blank. Whereas with triple buffering it can start drawing as soon as it finishes that frame at 20 ms and ends up raising your FPS since you have the image finished in time for many more intervals.

Unless I'm mistaken there.

All buffering causes input latency. With show-A/draw-B, show-B/draw-A (double buffering), they GPU is one frame behind the CPU, which is adding 16ms input lag (@60Hz).
Tripple buffering is show-A/draw-C, show-B/draw-A, show-C/draw-B, meaning the GPU is two frames behind the CPU, creating 33ms of latency (at 60Hz).

I thought the entire idea behind input lag was the time you press a button till the time you see it on screen. In that case in a best case scenario its 16.6 ms of delay with vsync on since present blocks until the blanking interval, meaning if you hit a button at 20 ms after drawing the first frame in 10ms you would see the first frame at 16.6, then the game loop probably misses your input until the next go around(done drawing at 26.6, waits till 33.2 to show your action) and so on.

Then with triple buffering if you are at say 45 fps instead of 60 you'd go something like..

Draw first frame in 22.2 ms, miss first interval, immediately start drawing next frame, 33.2 presents frame, player sees it and presses button in same period of time, input is in at 36.6, frame is done at 44.4, wait till 49.8, get player input and action gets worked into next frame, see next frame at 66.6. So basically give or take 30 ms delay.

Compared to just pure vsync at 45 fps you'd get dropped to 30 and still get the input in the same period of time roughly since the input would be queued up. So I guess it shouldn't make your input latency worse nor improve it?

Unless I have that wrong, I'm bad at doing this kind of stuff in my head. I'm not actually totally sure of implementation details, I was assuming that vsync with two buffers will block a present call until the vsync whereas with triple buffering it will not block but it won't present the recently drawn buffer until the next blanking interval. Maybe that's wrong. I've never really checked the behavior.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS