- To avoid the FPS drop when VSync is enabled (unless both GPU & CPU take less than 16ms to render).
- To let the CPU return immediately in case one frame was taking too long for the GPU to process.
In both cases, turning off VSync makes the triple buffering irrelevant:
- When VSync is off and CPU/GPU took more than 16ms; the buffers are still flipped and tearing appears (unless the rendering time was a multiple of 16ms).
- When VSync is off, the CPU still returns immediately from submitting the commands to the GPU; the screen is flipped and tearing happens.
Triple Buffer + No Vsync makes no sense (you can try it, but it won't change much); Triple Buffer + VSync should deliver similar performance to Double Buffer + No VSync; except there is no tearing but trading off a frame of latency. There is no way
to avoid the additional frame lag.
What Anandtech is saying with its "alternative" is basically just a form of frame-skipping: When the CPU is too fast (or the GPU is too slow); the CPU may be issuing 4 frames, but the GPU is still presenting the front buffer, the 1st backbuffer is waiting to be presented, and the 2nd backbuffer is also waiting; and the CPU wants a 4th one.
So, instead of using quadruple buffering or waiting, the Anandtech suggest the method of dropping the contents of the 2nd backbuffer and replace it with the contents of that 4th frame.
So the monitor will end up showing frames 1, 2, 4; instead of showing 1, 2, 3 ... wait ... 4.
Forcing frame 4 come after 2 leads to stuttering.
This is a terrible technique, it only works for the cases when the 5th frame will be very CPU intensive thus dispatching the 4th now instead of waiting gives a lot of time to process that heavy 5th frame.
But it is pointless anyway because if you have such bad fps micro-spikes you have a bigger issue; and besides it means the CPU is sending frames faster than the monitor's refresh rate
; which is pointless and only leads to stutter.
The other extreme is when the GPU is taking too long. But if the GPU takes too long all the time, then triple buffer won't help much; and you should be thinking of plain old frame skipping (regardless of buffer counts).
Another issue with the technique is that if the 4th frame is too GPU heavy, it won't be ready by the time it should be presented (that is, after frame 2), however had they waited, it could make it in time because there is one frame more in the queue (frame 3 comes after 2, then comes the 4th). Like I said, a terrible technique. The Anandtech article says their technique is the real Triple Buffer; while DX implements a fake render ahead queue that shouldn't be called Triple Buffering. Well, the article is wrong. Their technique is not "Triple Buffer"; it's a form of useless frame-skipping that introduces stutter, increases CPU power consumption, but is still able to avoid tearing and has as much visible lag as the "render ahead" method.
Edited by Matias Goldberg, 21 October 2013 - 12:06 PM.