Bug 44371 - vsync option for front-buffer rendering
Summary: vsync option for front-buffer rendering
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: lowest enhancement
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-01 12:20 UTC by r.goyet
Modified: 2015-02-18 15:38 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log file (19.82 KB, application/octet-stream)
2012-01-01 12:20 UTC, r.goyet
no flags Details

Description r.goyet 2012-01-01 12:20:53 UTC
Created attachment 55025 [details]
Xorg log file

Bug description:

When I drag a window around, I get some awful tearing (like illustrated here http://en.wikipedia.org/wiki/Screen_tearing ).

I believe the display is not synced to vblank, but that's just a wild guess as I'm far from being an expert in the field.

System environment: 
-- chipset: Atom N450 and PineView GM GPU
-- system architecture: 64-bit
-- xf86-video-intel: 2.13.0
-- xserver: 1.7.7
-- mesa: N/A
-- libdrm: N/A
-- kernel: 2.6.32
-- Linux distribution: Debian Stable
-- Machine or mobo model: HP Mini 110-3800
-- Display connector: Laptop

Reproducing steps:

Just start Xorg with any lightweight WM. JWM for instance. Open an xterm, and drag it around : I get very visible tearing.

Additional info:

I do not get any tearing when using OpenGL applications. A workaround is to go the "heavyweight" route, and use Compiz. Then tearing completely disappear.
Comment 1 Chris Wilson 2012-01-01 13:05:10 UTC
The current solution is indeed to use XComposite with sadly a DRI based compositor (ie compiz and the ilk). Whilst it would be possible to sync all front-buffer drawing to vblank this would be slower than using a back buffer and staging updates (even then the update is not synchronous with the client rendering, for that you want the wayland compositor model). However, it would be possible though I think the cure would be much worse than the disease. As you have already noticed, where it matters most it already is vsynced (video playback and GL swapbuffers).
Comment 2 Chris Wilson 2012-06-24 07:33:28 UTC
If you're keen to experiment you can try building from x86-video-intel.git with --enable-sna and add:

Option "AccelMethod" "sna"
Option "TearFree" "true"

to your Device section in xorg.conf.
Comment 3 Chris Wilson 2012-10-20 16:53:39 UTC
Looking at our product roadmap, vsync is a legacy feature and using it will cause a very high power drain. So I can not recommend that we start supporting such a flag.
Comment 4 Chris Wilson 2014-02-01 11:22:25 UTC
Also note that the Present extension will be available for non-DRI clients as well i.e. ideally suited for XRender compositors. (Will be, Present is still full of holes.)
Comment 5 Chris Wilson 2015-02-18 15:38:36 UTC
Whilst I was thinking of exposing this to clients, that doesn't really scale and so I am convinced that TearFree is the right solution here.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.