Using kernel 3.15 and the xorg intel driver 2.99.912 from a git build on 2014/06/11, I still get sometimes artifacts on window borders (they show stripes) when using xfwm4 and sna enabled (Originally reported on launchpad with screenshots: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1171411). Recently I found out, that it only happens with one specific theme (greybird-compact of recent xubuntu versions) and not with a quite similar one (greybird). xfwm4 decorates window borders by repeatedly drawing little xpms (left-*.xpm, right-*.xpm, bottom-*.xpm). The problematic theme uses 2x2 or 2x1 pixel xpms whereas the other uses 1x1 pixel xpms for those decorations. For now I just copied the corresponding 1x1 xpms to the greybird-compact theme, which works around the issue, but I guess there should be a real fix.
Can you please attach your Xorg.0.log so can I check hw details just in case they are relevant for reproducing this bug?
Created attachment 101102 [details] xorg log from Intel GMA 4500MHD Previous driver versions had this issue on several intel graphic cards, so it was probably hw independent. But since the frequency of appearance was reduced, when the font rendering issue were fixed, I'll try to reproduce it on a hd4600 (i5 haswell) to confirm, that it still concerns more than one hw type.
Created attachment 101107 [details] xorg log from hd4600 of a i5-4570S Got it! With a high redraw rate, e.g. resizing the window it's quite reproducible.
I haven't spotted Greybird-compact on either fc20 or Trusy. I presume I need to use something more recent then?
Ah, greybird-compat was a wm theme not in Appearance. I was looking in the wrong place.
I saw it once by resizing a terminal. But haven't managed to reproduce it since. Is resizing the best trigger?
> I saw it once by resizing a terminal. But haven't managed to reproduce it since. Is resizing the best trigger? Yes, the best way to trigger manually I've found so far, is to resize a firefox window with a render expensive web page open (funnily the news page of the german public-service broadcasters works best for me: www.tagesschau.de). Of course the 'hide window content when resizing'-option of xfwm4 should not be checked ;) .
Hmm. Still no luck. Could you check with xf86-video-intel.git? And then check a few versions back (e.g. 2.21.15 --with-default-accel=sna) to see if this would be bisectable?
(In reply to comment #8) > Hmm. Still no luck. Could you check with xf86-video-intel.git? And then > check a few versions back (e.g. 2.21.15 --with-default-accel=sna) to see if > this would be bisectable? I originally reported this issue (together with some more display distortions) against 2.21.6 (thats the version when ubuntu decided to enable sna by default). So I guess we would have to go even further back to 2.17.0 (?). If I remember correctly: the frequency with 2.21 was really high, about every 10th redraw due to window switching would trigger it. The frequency went massively down with (or slightly before) 2.99.210. Should I try to reproduce it on 2.17 then? I lack the experience, if bisecting under that conditions would make sense.
That's fine. I doubt that would be a worthwhile exercise. So back to the question of why I saw it once and never again... :|
(In reply to comment #10) > That's fine. I doubt that would be a worthwhile exercise. So back to the > question of why I saw it once and never again... :| I've tried to reproduce it again and it seems, that it's harder with the hd4600. But still, if grab the top left window corner and make circular movements (and thus continuously resizing the window), especially the left border shows sometimes the stripes and if you stop in the right moment they persist. Newer versions of xfwm4 have a zoom feature (when compositing is enabled) accessible by alt + mouse wheel, which one can use to watch more closely at flashing pixels while resizing. Btw the left border stripes are 4 pixel long and 2 pixel wide (and may have different colors on different tries) followed by a 4 pixel part displaying the correct pixmap.
I've been trying on two different machines, and have not spotted a single failure single that first go after updating to oneric. (I suspect I may have tested before replacing the system -intel driver.) Have you tested against the current xf86-video-intel.git just in case I did accidentally fix it? I doubt it, as it sounds very much like the pattern blt code is buggy.
Ok, I have a machine that I can sporadically trigger the bug. Not great reproducibility yet, but it's a start.
So I traced the error down to seemingly to the use of the source pixmap for drawing the border. (Basically by modifying the drawing operations until I found the exact path one of the window borders was taking, then tracing back the pixmap to its creation.) On that path I spotted this: commit d49f53cc00258e3b1e1a898c02e219b336716002 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jun 17 22:23:02 2014 +0100 sna: Fix computing source bo for BLT operations If we migrate the pixmap to the GPU, use the GPU bo. This may fix an issue where we might end up using the CPU bo in a rare circumstance. References: https://bugs.freedesktop.org/show_bug.cgi?id=80033 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> However, I never got the bug to reproduce reliably, so I am not sure if that the complete fix. Please test.
It happened again.
Hmm, here it feels very size dependent. Am I finally getting close to reliably reproducing this?
commit d49f53cc00258e3b1e1a898c02e219b336716002 did change something: Reproducibility increased drastically ;). But now seriously: I can't reproduce stripes on left/right borders anymore, but on the bottom border they are now more pronounced (mostly 2px wide with 6px normal border in between; was 1px/1px before) and much more frequent. In fact, bottom border stripes are now really easy to reproduce on both machines, most of the time it's enough to open just another window.
One step forward, one step back. Replace one source of random uninitialised data with a deterministic one instead! Let's try: commit e52f917a2370026073ed6851161393a69ee94abe Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jun 18 10:18:26 2014 +0100 sna: Use nxm tiled blits for small regions of large tiles If the region we are blitting is either narrow or short, we may be able to construct a tiling pattern out of a large pixmap. In the process, spot a regression due to commit 542aeca6e67fc64f9133ca3e27ac8eca28af6d25 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jun 17 12:26:30 2014 +0100 sna: Tweak creation 8x8 tiled patterns which copied too much from the source line. References: https://bugs.freedesktop.org/show_bug.cgi?id=79888 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #18) > One step forward, one step back. Replace one source of random uninitialised > data with a deterministic one instead! > > Let's try: > > commit e52f917a2370026073ed6851161393a69ee94abe > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Wed Jun 18 10:18:26 2014 +0100 > > sna: Use nxm tiled blits for small regions of large tiles > > If the region we are blitting is either narrow or short, we may be able > to construct a tiling pattern out of a large pixmap. > > In the process, spot a regression due to > > commit 542aeca6e67fc64f9133ca3e27ac8eca28af6d25 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Tue Jun 17 12:26:30 2014 +0100 > > sna: Tweak creation 8x8 tiled patterns > > which copied too much from the source line. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=79888 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Again much harder to catch, but bottom stripes are still there. All sorts of pattern appear (I'm wondering where the colors come from), but the period is 8px (where applicable).
If you are certain it is a repeating pattern, then it the BLT being loaded up with garbage. The BLT takes an 8x8 pattern to be repeated, so it that matches the repeat distance I know it is still junk being fed into that command. :| Have you refined your test? Could you?
I just pushed another patch for the construction of 8x8 patterns from larger tiles, worth testing again. Though I don't think it should have affected you.
(In reply to comment #20) > If you are certain it is a repeating pattern, then it the BLT being loaded > up with garbage. The BLT takes an 8x8 pattern to be repeated, so it that > matches the repeat distance I know it is still junk being fed into that > command. :| > > Have you refined your test? Could you? Never saw a periodicity longer than 8px; sometimes shorter, but that could be just because the garbage has a pattern. I've replaced the offending xpm with a 3px/4px wide one. With the 3px one I couldn't see any stripes, only the right edge of the bottom border shows sometimes a wrong pixel. With 4px it's basically the same as with 2px (maybe a bit less frequent) and a period of 8px again. And another observation (tested with commit d49f53cc00258e3b1e1a898c02e219b336716002, because it's much easier to reproduce): The stripes appear if the bottom border is >1009px (or 1013 if one includes the corner pixmaps).
(In reply to comment #22) > (In reply to comment #20) > > If you are certain it is a repeating pattern, then it the BLT being loaded > > up with garbage. The BLT takes an 8x8 pattern to be repeated, so it that > > matches the repeat distance I know it is still junk being fed into that > > command. :| > > > > Have you refined your test? Could you? > > Never saw a periodicity longer than 8px; sometimes shorter, but that could > be just because the garbage has a pattern. > > I've replaced the offending xpm with a 3px/4px wide one. With the 3px one I > couldn't see any stripes, only the right edge of the bottom border shows > sometimes a wrong pixel. With 4px it's basically the same as with 2px (maybe > a bit less frequent) and a period of 8px again. That confirms it is the NxM conversion to 8x8 that is still upset. Did you test commit c257c936b42b92827b784cee0b7caa54e6040364 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jun 18 22:15:42 2014 +0100 sna: Fix modulus for partial conversion of tiles to 8x8 patterns ? > And another observation (tested with commit > d49f53cc00258e3b1e1a898c02e219b336716002, because it's much easier to > reproduce): The stripes appear if the bottom border is >1009px (or 1013 if > one includes the corner pixmaps). I believe that is just the theme deciding to use a staging pixmap for wide outlines. (Incorrectly, I might add since the hardware is more efficient doing the operation in place twice than once to a pixmap then copying it.)
(In reply to comment #23) > That confirms it is the NxM conversion to 8x8 that is still upset. Did you > test > > commit c257c936b42b92827b784cee0b7caa54e6040364 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Wed Jun 18 22:15:42 2014 +0100 > > sna: Fix modulus for partial conversion of tiles to 8x8 patterns > > ? > Same as before with the addition, that I now get sometimes the stripes on the top border as well which is build of 2x18px xpms.
Next correction to that pesky little function: commit edeb2ddd170a1817ced45abada53346c5cd8c30b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 19 11:51:00 2014 +0100 sna: Use the right pattern origin for tiled 8x8 extraction References: https://bugs.freedesktop.org/show_bug.cgi?id=80033 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Are we nearly there yet?
Btw a 9x2px bottom xpm (ie with a width >8px) causes the border to be rendered correctly. (In reply to comment #23) > > And another observation (tested with commit > > d49f53cc00258e3b1e1a898c02e219b336716002, because it's much easier to > > reproduce): The stripes appear if the bottom border is >1009px (or 1013 if > > one includes the corner pixmaps). > > I believe that is just the theme deciding to use a staging pixmap for wide > outlines. (Incorrectly, I might add since the hardware is more efficient > doing the operation in place twice than once to a pixmap then copying it.) Any chance the theme engine screws things up?
(In reply to comment #26) > Btw a 9x2px bottom xpm (ie with a width >8px) causes the border to be > rendered correctly. Right, 8x8 is the magic size that the hardware accelerates. Smaller than that and we try and build an 8x8 tile out of the smaller unit. Larger than that, we try to extract an 8x8 tile for automatic repetition, or otherwise we manually repeat the pattern. > (In reply to comment #23) > > > And another observation (tested with commit > > > d49f53cc00258e3b1e1a898c02e219b336716002, because it's much easier to > > > reproduce): The stripes appear if the bottom border is >1009px (or 1013 if > > > one includes the corner pixmaps). > > > > I believe that is just the theme deciding to use a staging pixmap for wide > > outlines. (Incorrectly, I might add since the hardware is more efficient > > doing the operation in place twice than once to a pixmap then copying it.) > > Any chance the theme engine screws things up? Just misses the hw fast path. The corruption here is entirely the drivers fault.
(In reply to comment #25) > Next correction to that pesky little function: > > commit edeb2ddd170a1817ced45abada53346c5cd8c30b > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Jun 19 11:51:00 2014 +0100 > > sna: Use the right pattern origin for tiled 8x8 extraction > > References: https://bugs.freedesktop.org/show_bug.cgi?id=80033 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Are we nearly there yet? (In reply to comment #25) > Next correction to that pesky little function: > > commit edeb2ddd170a1817ced45abada53346c5cd8c30b > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Jun 19 11:51:00 2014 +0100 > > sna: Use the right pattern origin for tiled 8x8 extraction > > References: https://bugs.freedesktop.org/show_bug.cgi?id=80033 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Are we nearly there yet? Nearly, no stripes anymore, but now the window edges are effected: top right which is a 8x18px and bottom left/right (4x4px). Those bottom edge corruptions sometimes keep their position relative to the top edge, ie if I enlarge the window to the top they get 'pulled' into the window border.
This is getting ridiculous: commit 6b32cf3a3c908bd29496fcf5d190fd0f8c657ae6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 19 12:29:58 2014 +0100 sna: Missed fixing y tile offset in last commit Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #29) > This is getting ridiculous: > > commit 6b32cf3a3c908bd29496fcf5d190fd0f8c657ae6 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Jun 19 12:29:58 2014 +0100 > > sna: Missed fixing y tile offset in last commit > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> I'm sorry, it's still there, pretty theme independent though. The pattern is now quite hard to grasp. Right top and bottom corner: one or several miss colored pixel in a certain area (I'd say larger than 8x8 at least for the bottom corner), Left bottom corner: wrong pixel line up on the left edge, effected area might be higher than 8px. However, beside the near corner region, everything looks fine.
commit d2b90ac969656de35ec86973f66074654b0e9b4b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 20 14:29:43 2014 +0100 sna: Color patterns for BLT are required to be aligned to 256 byte boundaries This so far appears to be the most restrictive alignment required, so simply increase the upload alignment to 256 bytes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80033 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> That was not an enjoyable discovery.
Snuck in a tiny little bugfix into commit 219f6bd9e863f9c89cc4168895f89741ce6dbcbb Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 20 17:06:55 2014 +0100 sna: Be more flexible in converting random subsamples to 8x8 tiles Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Should be ready for testing.
(In reply to comment #32) > Snuck in a tiny little bugfix into > > commit 219f6bd9e863f9c89cc4168895f89741ce6dbcbb > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Fri Jun 20 17:06:55 2014 +0100 > > sna: Be more flexible in converting random subsamples to 8x8 tiles > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > > Should be ready for testing. Yes, yes, yes, no more artifacts (build from b3d3c0e8e75a963262e4dc463fef60d7e9f1f01a). I'm going to test it a bit more (just to be sure), but most likely we can close this issue. Thanks a lot.
Time to provoke the bug by proclaiming it fixed!
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.