Jump to content
  • Advertisement
Sign in to follow this  

Negatives to Triple Buffering?

This topic is 2006 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!