Tearing and buffers

[Raum]

I just witnessed a discussion about screen tearing, and I don't really get how the buffers function without v-sync.

Can someone explain what actually happens with single, double and triple frame buffers in detail?

... and yes, I saw the post about buffers here on the site, but it really doesn't go into detail (for example, I'd like to know what actually happens when "In the old days there was only one buffer and it was continually being both drawn to and sent to the monitor").

It's impossible to understand what's actually going on without some in-depth analysis of the frame buffer itself and how it functions.

 

[Cogman]

There really isn't a whole lot to buffers. Buffers are basically just chunks of memory that store data.

Here's whats going on with double/triple and no buffering.

No buffering. The video card writes pretty much directly to output. The result is that things tear, pretty badly. The video card is usually caught mid drawing during a screen refresh, and thus, things don't always match up.

Double buffering simply means that you have two frames that the video card is working on. When it finishes one frame completely (think of taking a snapshot) it switches it and starts drawing on the next buffer. This allows the video card to have pixels read to draw each refresh. It somewhat reduces tearing as the operation of swapping buffers is pretty quick, so the chances of catching things mid drawing is reduced.

Triple buffering is double buffering with another buffer, it rotates through the 3 buffer frames.

Vertical sync removes tearing completely, but must be associated with double buffering (ok, it doesn't HAVE to be, but it should be). It times drawing on the screen so that the screen refresh isn't caught during a refresh cycle, in other words, no half frames.

IMO, with double buffering and V-sync, there is no reason for triple buffering. The most triple buffering will do in this case is slightly smooth out frame droops (if 2 frames render fast, the 3rd will have more time to process, in theory at least).

 

[Raum]

Like I said, I've already read most about buffering that is out there. I want to know what is actually going on. Not the Simple English Wikipedia version.

Like, nobody says how the drawing of the buffers work in terms of timing. What decides when the double buffer switches. What, when there's a single draw buffer, happens when a new buffer is started before the old one is drawn to the monitor. It's stated that there was issues with "flicker" with the old one buffer system. Why?

I want the details.

 

[DominionSeraph]

IMO, with double buffering and V-sync, there is no reason for triple buffering. The most triple buffering will do in this case is slightly smooth out frame droops (if 2 frames render fast, the 3rd will have more time to process, in theory at least).

Triple buffering makes a BIG difference if you're processing under your refresh rate. With double buffering, you'll drop straight down to a FPS of one-half refresh.

 

[bobsmith1492]

Check out AT's article from a while back; there is some good detail here on page 3:
http://www.anandtech.com/show/2794/3

 

[Cogman]

Like I said, I've already read most about buffering that is out there. I want to know what is actually going on. Not the Simple English Wikipedia version.

That IS what is going on. Data movement and register storage isn't really all that interesting, but if you want an explanation of how it works, I'll be happy to give it.

Like, nobody says how the drawing of the buffers work in terms of timing.

Timing is all on the driver/video card. The buffers are stored on the video card and the video card does the switching. The program will signal the video card (via the drivers) that a switch is ready. When V-sync is on, the driver holds the execution path for the program and draws when it is doing a refresh. If by some odd reason, it misses the refresh, it waits for the next.

What decides when the double buffer switches.

V-sync on, the video card
V-sync off, the program.

What, when there's a single draw buffer, happens when a new buffer is started before the old one is drawn to the monitor.

A new buffer isn't started. There is only one. The place that is being displayed and written on is the same. Nothing, per-say, happens other then the information is outdated (depending on how fast the program is running in comparison to the refresh) What is written stays on screen, what hasn't been written will be updated and the updated version will be written on screen.

It's stated that there was issues with "flicker" with the old one buffer system. Why?

I want the details.

See the above explanation. Data is being updated, potentially several times on each pixel before it is being written on screen. So one pixel may be 3 or 4 frames old with each refresh (frame rate doesn't necessarily follow monitor refresh rate)

 

[Cogman]

Triple buffering makes a BIG difference if you're processing under your refresh rate. With double buffering, you'll drop straight down to a FPS of one-half refresh.

With triple buffering, the same thing happens if the scene is complex for more then 2 frames. Rather then buying you 1 frame it buys you two. which, imo is somewhat pointless.

 

[DominionSeraph]

With triple buffering, the same thing happens if the scene is complex for more then 2 frames. Rather then buying you 1 frame it buys you two. which, imo is somewhat pointless.

LOL you're thinking of this like audio or video buffering. It's an issue with waiting for VSYNC and the card having no place to put data.

Double buffering:
Refresh: 16.666ms
Card processes a frame in 17ms

00.0ms Frame1: Output buffer 1
16.6ms Frame2: Output buffer 1 again as buffer 2 isn't ready.

17.0ms Back buffer becomes ready. Waiting for VSYNC. Card idles for the next 16.3ms because all buffers are full.

33.3ms Frame4: Flip buffers/Output buffer 2/ NOW we can start processing and writing the results to buffer 1.
50.0ms Frame5: Output buffer 2 again (buffer 1 not ready for .33ms)

50.33ms Buffer 1 becomes ready. Wating for VSYNC. Card idle.

66.6ms Output buffer 1/start writing to buffer 2
100ms Ouput buffer 1 (buffer 2 not ready for .33ms)

30FPS output when the card can process at 17ms/58.8FPS because the card is idling 49% of the time due to insufficient buffers.


Triple buffering:

00.0ms Frame1: Output buffer1
16.6ms Frame2: Output buffer1 (since we're assuming none of the back buffers have had the requisite 17ms prior to frame1 to fill, we get a double output here.)

17ms Buffer 2 is ready. Waiting for VSYNC. But now that we're using triple buffering, we can use this time to process the next frame and write to buffer 3.

33.3ms Frame3: Output Buffer2

34ms Buffer 3 is ready. Waiting for VSYNC. Begin writing to buffer 1

49.9ms Frame4 Output buffer3

51ms Buffer 1 is ready. Waiting for VSYNC. Begin writing to buffer 2


Frame5 Buffer1
Frame6 Buffer2
Frame7 Buffer3
Frame8 Buffer1
Frame9 Buffer2
Frame10 Buffer3

Around frame 60 we'll get another double output of a buffer because the processing can't quite keep up with the refresh rate. By second it'll look something like:

58 frames
59
59
59
59
59
59
58
59
59
59
59
59
59

For 58.8 FPS

Triple buffering always leaves your card someplace to write to.