| Summary: | DRI2 doesn't support SGI_video_sync extension | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Daniel Gnoutcheff <daniel> |
| Component: | Drivers/DRI/i965 | Assignee: | Jesse Barnes <jbarnes> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | high | CC: | bojan, haien.liu, sam, tmezzadra |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Xorg.0.log
xorg.conf Xorg.1.log with latest 2D driver |
||
|
Description
Daniel Gnoutcheff
2009-06-08 17:21:16 UTC
Created attachment 26570 [details]
Xorg.0.log
As per standard procedure.
Created attachment 26571 [details]
xorg.conf
Normally, I run with a really minimal xorg.conf that has an "Option DontZap off" and nothing else, but as per procedure I generated an xorg.conf with X -configure and edited it slightly.
Kernel messages showing system+Xorg bootup found at: http://www.vu.union.edu/~gnoutchd/bugs/intel-vblank/kern-log Warning: 4.4 megabytes! (i.e. too big to attach) That log was made with drm.debug=1, so that's why it's so big. ;) Note that hat log was actually extracted from syslog, standard kernel message buffer wasn't big enough. :) If desired, I can reboot without such verbose debugging and attach a more "normal" dmesg. Any additional info/tests are just a request away ;) This should be fixed in git master of the 2D driver, can you give it a try? Created attachment 26611 [details] Xorg.1.log with latest 2D driver (In reply to comment #4) > This should be fixed in git master of the 2D driver, can you give it a try? Done. I'm afraid upgrading does not help, it makes no noticeable change in behavior. Xorg log attached. I've tried upgrading only the 2D driver, and I've also tried going for broke and compiling *everything* from git. Neither fixes this bug. I should note, though, that when I install everything from from git I start getting lots of segfaults - another issue I have to investigate and probably file bug(s) for. For example, the attached log shows a crash on xterm exit. Also, with with latest xserver, I get a segfault immediately on server start, making it impossible to test for this bug. Because of this, I'm currently testing with a self-compiled xserver that matches the version from X-edgers. Ahh.. the -ss option doesn't work with DRI2... we haven't hooked it up yet. -sb should work ok though since it uses buffer swaps (those do the vblank waiting in the server). Since SGI_video_sync shouldn't be used to avoid tearing anyway, I don't think this is a huge issue (swapbuffers is the most reliable way to avoid tearing). (In reply to comment #6) > Ahh.. the -ss option doesn't work with DRI2... we haven't hooked it up yet. > -sb should work ok though since it uses buffer swaps (those do the vblank > waiting in the server). > > Since SGI_video_sync shouldn't be used to avoid tearing anyway, I don't think > this is a huge issue (swapbuffers is the most reliable way to avoid tearing). OK, yes, -sb does work correctly, no tearing there. Any idea how soon SGI_video_sync will be implemented, if ever? Because if it's not "soon", I really do think that something should be done about the dmesg spamming, at least. When vsync is turned on in compiz (as it is by default), my system logs very quickly grow to hundreds of megabytes, even with drm.debug=0. > 2009-06-10 10:50:31 PST --- (In reply to comment #6)
> > Ahh.. the -ss option doesn't work with DRI2... we haven't hooked it
> > up yet. -sb should work ok though since it uses buffer swaps (those
> > do the vblank waiting in the server).
> >
> > Since SGI_video_sync shouldn't be used to avoid tearing anyway, I
> > don't think this is a huge issue (swapbuffers is the most reliable
> > way to avoid tearing).
>
> OK, yes, -sb does work correctly, no tearing there.
>
> Any idea how soon SGI_video_sync will be implemented, if ever?
> Because if it's not "soon", I really do think that something should
> be done about the dmesg spamming, at least. When vsync is turned on
> in compiz (as it is by default), my system logs very quickly grow to
> hundreds of megabytes, even with drm.debug=0.
It might be soon, it shouldn't actually be too hard. But yeah I'll get
rid of the message for 2.6.31 as well. It's really just debug output
to indicate that userspace tried to wait on a disabled pipe (which is
bad, but we shouldn't spam the log about it, since the return value
will be enough).
Jesse
*** Bug 22492 has been marked as a duplicate of this bug. *** *** Bug 22056 has been marked as a duplicate of this bug. *** increasing priority as it impacts moblin: http://bugzilla.moblin.org/show_bug.cgi?id=6488 Support added by mesa c6ef705e414c8e93ee471f50d15ada3492a9b067, xserver 04a54f69a8085ab3fe11a8713bd8b6b16ed1db27, and xf86-video-intel 51c75906329a4727e37c8d1f64f257ea9602caa2. |
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.