X: 25 years and still lacking vsync'ed double buffering [LWN.net]

X: 25 years and still lacking vsync'ed double buffering

Posted Sep 28, 2009 19:14 UTC (Mon) by alankila (guest, #47141)
In reply to: X: 25 years and still lacking vsync'ed double buffering by dion
Parent article: LPC: 25 years of X

It will work with OpenGL. You just post a new frame and the hardware switches to it during the frame
sync. Since there are only two buffers in doublebuffering, it follows that GLSwapBuffers() must sleep
until the swap is possible. Looking at the wider topic: perhaps it would be better to forget about X
and instead rewrite toolkits on top of OpenGL and then have OpenGL server instead of X server...

to post comments

X: 25 years and still lacking vsync'ed double buffering

Posted Sep 28, 2009 20:54 UTC (Mon) by drag (guest, #31333) [Link] (9 responses)

Ya.. That was the original idea behind the now-oldschool XGL and whatnot.

Rewrite everything to run on OpenGL and then use OpenGL drivers to drive everything.

That effort is what lead to Kernel-Mode-Setting (OpenGL has no API for display control) and proper in-Kernel memory management. (having lots of applications open will use more video RAM then there is video RAM at one point or another).

Of course driving 2D displays on OpenGL is a huge pain in the ass. So that is why we have Gallium were you have 1 driver to drive multiple APIs.

API State Tracker --> Gallium Winsys --> DRI2 --> Linux-DRM --> Hardware

Instead of:
EXA/XAA/Xv --> X DDX --> Hardware
+
OpenGL --> DRI --> Linux-DRM --> Hardware
+
Codec decoding accel --> NULL
+
OpenVR --> NULL
+
OpenCL --> NULL

etc etc.

Anyways this is a better design since the world has moved on from OpenGL acceleration to much more general purpose GPUs with programmable shading languages and other things. This is leading to a full-featured GPGPUs which we will see in a year or two. This is were the GPU is just a co-processor of sorts and 'video acceleration' is just software that is compiled/designed/optimized to use the coprocessor as well as the GPU.

X: 25 years and still lacking vsync'ed double buffering

Posted Sep 28, 2009 20:56 UTC (Mon) by drag (guest, #31333) [Link]

er..
not "coprocessor as well as the GPU"

but: GPU coprocessor as well as the CPU.

X: 25 years and still lacking vsync'ed double buffering

Posted Sep 30, 2009 15:39 UTC (Wed) by dgm (subscriber, #49227) [Link] (7 responses)

Well, if I understood it right, XGL was about implementing X over OpenGL. What dion suggested instead was bypassing X, and make toolkits talk directly with the OpenGL driver. It has been suggested many times in GTK, as explained in this article, that also enumerates most of the reason why it's not a good idea: http://blogs.gnome.org/timj/2007/07/17/17072007-opengl-fo...

Also, network transparency and multiple displays make synchronizing with the vertical retrace a complex matter. What's more, current LCD monitors and other display technologies like e-paper do not do any vertical retrace (AFAIK).

In my opinion, what would be useful is some means to avoid unnecessary work in applications. What's the point of repainting the screen at 1200 fps when only 60 can be displayed due to limitations in the display? Wouldn't it be better to save all that wasted power?

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 2, 2009 7:49 UTC (Fri) by hrydgard (guest, #54085) [Link] (6 responses)

LCD monitors absolutely do vertical retrace, it's just not as visible, but
tearing remains a problem. How else would the signal get to the display, did
you think there were individual wires from each cell of framebuffer memory
to each pixel on the display?

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 2, 2009 17:02 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

vertical retrace interval is an artifact of the CRT and the fact that it takes time to steer the electron beam from the bottom of the display back up to the top of the display.

on an LCD it takes no more time to go from the bottom of the display to the top of the display than it takes to go from the first row to the second row.

in any case, the cause of tearing was caused by disrupting the sync signals (most commonly the horizontal sync at the beginning of each line) causing the display to 'tear' horizontally across the screen. by waiting to update the video ram until the vertical retrace period (when the CRT isn't displaying anything anyway)you avoided causing this problem.

with dual-port ram or a digital feed to the display this problem just doesn't exist

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 2, 2009 17:39 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (3 responses)

LCDs aren't (in the relevant cases) pixel addressable devices. The framebuffer is still scanned out at the vertical refresh rate and the entire image sent to the LCD each time - starting at the top left pixel and finishing at the bottom right. There's even an interval between the end of a frame and the beginning of the next one.

Whatever the original meaning of the word "tearing" as relating to video, its use to describe the effect caused by framebuffer updates not being synchronised with scanout and the associated discontinuity in the image is well established.

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 2, 2009 17:59 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

if a LCD is connected via a VGA interface include the vertical retrace delay, ones connected via digital interfaces do not.

having an image change halfway through an update from one frame to the next with no other distortion of the screen (and cleaned up on the next frame refresh) is a _very_ minor issue compared to loosing sync which scrambles the screen for a significant amount of time (several seconds on a LCD)

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 2, 2009 18:02 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (1 responses)

"if a LCD is connected via a VGA interface include the vertical retrace delay, ones connected via digital interfaces do not."

They do. A *lot* depends on having that interval available.

"having an image change halfway through an update from one frame to the next with no other distortion of the screen (and cleaned up on the next frame refresh) is a _very_ minor issue compared to loosing sync which scrambles the screen for a significant amount of time (several seconds on a LCD)"

The common case is watching videos or playing games, where it's not cleared up on the next frame refresh because another update has happened in the meantime. It manifests itself as a consistent discontinuity in the image. It's greatly irritating.

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 11, 2009 22:24 UTC (Sun) by Ross (guest, #4065) [Link]

> They do. A *lot* depends on having that interval available.

Yes, but the delay between updates can be very small in comparison to what are needed for CRTs. This can even be taken advantage of with normal analog VGA connections to get a higher refresh rate and/or resolution with the same pixel clock (see reduced blanking modes).

> The common case is watching videos or playing games, where it's not cleared up on the next frame refresh because another update has happened in the meantime. It manifests itself as a consistent discontinuity in the image. It's greatly irritating.

Or it may slowly move up or down the screen. It can be very distracting in the right situation.

-Ross

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 11, 2009 22:18 UTC (Sun) by Ross (guest, #4065) [Link]

But usually they retrace many strips of the screen in parallel (otherwise the refresh rate would be too slow). So it's not exactly a vertical retrace that you want to know about, but a way to avoid drawing operations during display updates.

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 2, 2009 6:45 UTC (Fri) by Tuxie (guest, #47191) [Link] (1 responses)

This is effectively fixed by enable triple buffering in xorg.conf.

Without triple buffering, playing videos with a similar but not exact multiple of the screen Hz (like 29.97 FPS video on a 60 Hz display) can cause problems. MPlayer can come to a situation where each frame is finished just after the vblank so it will stall waiting for vblank most of the time, leaving little time left to do actual decoding, resulting in very choppy playback. This is especially visible on low Hz modes like "24p" (23.976 Hz) and HD video. Enabling triple buffering solves this.

It doesn't however fix the problem with drifting audio/video sync when video/screen Hz only almost match. For that you need either hard frameskips or syncing audio to video with resampling or AC3/DTS packet dropping/duplication, which AFAIK only recent SVN snapshots of XBMC can do on Linux systems. MPlayer and stable XBMC sync video to audio.

For some reason (Nvidia driver bug?) though, triple buffering cause problems with Nvidia hardware decoding/rendering (VDPAU) so if you rely on VDPAU to do your video playback you will want to disable it.

It will also cause a display lag of one frame so you may want to disable it for fast paced FPS games.

X: 25 years and still lacking vsync'ed double buffering

Posted Oct 8, 2009 7:52 UTC (Thu) by kragil (guest, #34373) [Link]

Triple buffering, yeah!
It is fun to see that a concept that I used in the Amiga arcade games I wrote as a kid is now a solution to X problems.

It probably is true what they say, that most of hard CS problems were solved in the 60s (I just takes a few generations to implement them everywhere)