View Single Post
Old 10-26-10, 04:17 PM   #12
Registered User
Join Date: May 2004
Posts: 711
Default Re: Why does it take 6 steps to get nvidia + compiz running smooth, fast, not torn ?

Originally Posted by bearoso View Post
Triple buffering can cause an extra frame's worth of latency, which is VERY bad in terms of responsiveness. Imagine moving a window with a compositor on, and the window lagging several frames behind the mouse cursor.

So there you have it. Triple buffering gives you all the benefits of double buffering with no vsync enabled in addition to all the benefits of enabling vsync. We get smooth full frames with no tearing. These frames are swapped to the front buffer only on refresh, but they have just as little input lag as double buffering with no vsync at the start of output to the monitor. Even though "performance" doesn't always get reported right with triple buffering, the graphics hardware is working just as hard as it does with double buffering and no vsync and the end user gets all the benefit with out the potential downside. Triple buffering does take up a handful of extra memory on the graphics hardware, but on modern hardware this is not a significant issue.
The cause of the tearing everyone's getting even with vsync is a client-side wait in compiz (via GLX_SGI_video_sync). It uses a dirty-rectangles approach most of the time, preventing page-flipping and making display susceptible to scheduler interference. So most of the time the output frame is drawn partially during scan-out.

This can be fixed by using a buffer swap with only driver-side vsync every time. A page flip is completed very quickly by the video card and there's no tearing. There's two problems with this:

1. Buffer swaps on the video card occur asynchronously with respect to compiz. So compiz continues running and picks up input and graphics data for the next frame in advance--accumulating an additional frame of input-lag. This can be eliminated by waiting until the current framebuffer is complete by using glFinish or glXWaitGL immediately after the swap-buffers call.

2. Redrawing the whole screen is more expensive than only redrawing parts. Arguably, this is a moot point because all the graphic content is in video memory and framebuffer->framebuffer writes are so fast. It is, however, the main reason people mention for not doing it.
You missed my point, I was not referring to compiz at all, but doing gl rendering without synchronization will pretty much always result in tearing, and playing a game with tearing (at least to me) isn't fun (I was just replying to the "vsync is BAD rant").
Dragoran is offline   Reply With Quote