Summary: | [integrated G33] Glyph and pixmap corruption | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Matti Hämäläinen <ccr> | ||||||||||
Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||||||
Status: | RESOLVED DUPLICATE | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||
Severity: | normal | ||||||||||||
Priority: | medium | ||||||||||||
Version: | 7.6 (2010.12) | ||||||||||||
Hardware: | x86 (IA32) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Attachments: |
|
Description
Matti Hämäläinen
2011-05-31 02:11:41 UTC
Created attachment 47351 [details]
Screenshot of the glyph corruption
Created attachment 47377 [details]
Xorg startup logfile
The same problem still persists with latest GIT of xf86-video-intel ( afdb8aa89a88c62ccd5e26a3ed9adb70fec310a8), without SNA enabled. With SNA enabled, I haven't seen this problem, but unfortunately enabling SNA causes other problems (visible redrawing/flickering with xterm/rxvt and window moving (WindowMaker 0.92 as WM), etc) Kernels tested: 2.6.39.4 and 3.0.3 X.Org X Server 1.10.4 Xorg packages are latest available in Debian Testing, but using xf86-video-intel built from GIT repo source. As before, reverting the commit mentioned in first comment "fixes" the corruption problem. Please advise if you require any other information I have not provided yet. Created attachment 50977 [details]
Google Maps graphical corruption
Screenshot of the pixmap(?) corruption that occurs when using Google Maps with Firefox 7.0. Corruption does not occur with SNA enabled.
WindowMaker shouldn't be unusual in this regard. Can you describe the flicker more? Is it simply vrefresh tearing or is it always the same part of the screen flickering (such as the bottom third, or below the cursor) independent of the contents being updated? Running with --enable-sna --enable-debug=full is likely to slow down the system and hide the flicker, and is unlikely to tell me anything since you are not doing anything unusual. So back to describing the flicker. :) Well, I am no expert, but moving windows looks as the drawing of the window outline is shown without vsync (I do not use "opaque move", so only the outline is visible when moving). Xterm and rxvt window updates (when text is scrolled) on the other hand, look as if the window is first cleared (to black) and then text being repainted. I'd suspect this also has something to do with vsync, but ... *shrug*. :) Some other software also exhibit similar issues, but those two are the most prominent and especially the terminal "flickering" is very annoying. I am using a CRT monitor, if that has any relevance (shouldn't). Just adding this: it's as if there was no page flipping / double buffering performed (not that I have any idea if there should be :) ) Also, the drawing operations generally seem somehow "sluggish", though I don't know how to elaborate more on that. It could be just a placebo effect caused by the flicker/redraw visibility. Ok, you are just describing how rendering is done in a non-composited desktop, that is all individual operations are done immediately onto the front buffer and so you can see windows that are repainted multiple times. The only difference introduced by SNA in this regard is that it rate-limits it updates. Can you perceive a difference with...? diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c index 8a7cec2..5b6584e 100644 --- a/src/sna/sna_accel.c +++ b/src/sna/sna_accel.c @@ -3216,7 +3216,7 @@ static Bool sna_accel_do_flush(struct sna *sna) /* Then periodic updates at 25Hz.*/ to.it_interval.tv_sec = 0; - to.it_interval.tv_nsec = 40 * 1000 * 1000; + to.it_interval.tv_nsec = 10 * 1000 * 1000; timerfd_settime(sna->timer[FLUSH_TIMER], 0, &to, NULL); sna->timer_active |= 1 << FLUSH_TIMER; How bizarre, I feel the same when switching back to UXA. ;-) Heh .. Well, I'm not seeing much of difference with the patch applied. I also tried reducing the value even more, but with no perceivable consequences. Though I have to say, that part of the biggest problem is probably rxvt itself. With xterm and rxvt-unicode there is almost no "update flicker", I suppose they handle redrawing differently or use client-side double buffering. I assume you are not interested in the original problem, aka the glyph + pixmap corruption with SNA disabled? :) If so, it is understandable, of course. It worries me that I don't understand how the original issue occurs (it's not one of the known tiling issues), but ignorance is bliss if I have a path to a perfect future... Yeah. I think I'll just dump rxvt for urxvt and bear with the window movement etc. flicker for now. I also tested changing the sna_accel_do_flush() timer values to something ridiculously low, (to.it_value.tv_nsec = 1 * 1000 * 1000; and to.it_interval.tv_nsec = 1 * 1000 * 1000;) and this seems to improve things visually a bit. But I wonder if this may have some unwanted side-effects? I've pushed a tree to remove some of the optimisations to see if they are the cause of the corruption: http://cgit.freedesktop.org/~ickle/xf86-video-intel #glyph-cache-bug Can you please try this branch to see if does the trick? Rough guide to testing: $ git clone git://people.freedesktop.org/~ickle/xf86-video-intel $ cd xf86-video-intel $ git checkout origin/glyph-cache-bug $ ./autogen.sh --prefix=/usr $ make $ sudo make install # restart X *** This bug has been marked as a duplicate of bug 36326 *** |
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.