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 20:54 UTC (Mon) by drag (guest, #31333)
In reply to: X: 25 years and still lacking vsync'ed double buffering by alankila
Parent article: LPC: 25 years of X

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 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.