Bug 80033 - [sna] Occasional artifacts on window borders (theme dependent)
Summary: [sna] Occasional artifacts on window borders (theme dependent)
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-14 19:46 UTC by b3nmore
Modified: 2014-06-23 09:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg log from Intel GMA 4500MHD (24.24 KB, text/plain)
2014-06-15 15:37 UTC, b3nmore
no flags Details
xorg log from hd4600 of a i5-4570S (24.60 KB, text/plain)
2014-06-15 16:47 UTC, b3nmore
no flags Details

Description b3nmore 2014-06-14 19:46:18 UTC
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.
Comment 1 Chris Wilson 2014-06-15 05:54:28 UTC
Can you please attach your Xorg.0.log so can I check hw details just in case they are relevant for reproducing this bug?
Comment 2 b3nmore 2014-06-15 15:37:29 UTC
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.
Comment 3 b3nmore 2014-06-15 16:47:06 UTC
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.
Comment 4 Chris Wilson 2014-06-16 07:35:18 UTC
I haven't spotted Greybird-compact on either fc20 or Trusy. I presume I need to use something more recent then?
Comment 5 Chris Wilson 2014-06-16 09:12:42 UTC
Ah, greybird-compat was a wm theme not in Appearance. I was looking in the wrong place.
Comment 6 Chris Wilson 2014-06-16 09:56:25 UTC
I saw it once by resizing a terminal. But haven't managed to reproduce it since. Is resizing the best trigger?
Comment 7 b3nmore 2014-06-16 11:48:59 UTC
> 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 ;) .
Comment 8 Chris Wilson 2014-06-16 12:35:34 UTC
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?
Comment 9 b3nmore 2014-06-16 13:50:22 UTC
(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.
Comment 10 Chris Wilson 2014-06-16 14:15:26 UTC
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... :|
Comment 11 b3nmore 2014-06-16 17:41:58 UTC
(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.
Comment 12 Chris Wilson 2014-06-17 08:27:17 UTC
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.
Comment 13 Chris Wilson 2014-06-17 16:36:09 UTC
Ok, I have a machine that I can sporadically trigger the bug. Not great reproducibility yet, but it's a start.
Comment 14 Chris Wilson 2014-06-17 21:49:26 UTC
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.
Comment 15 Chris Wilson 2014-06-17 21:58:39 UTC
It happened again.
Comment 16 Chris Wilson 2014-06-17 21:59:52 UTC
Hmm, here it feels very size dependent. Am I finally getting close to reliably reproducing this?
Comment 17 b3nmore 2014-06-18 07:57:14 UTC
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.
Comment 18 Chris Wilson 2014-06-18 10:06:02 UTC
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>
Comment 19 b3nmore 2014-06-18 17:59:09 UTC
(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).
Comment 20 Chris Wilson 2014-06-18 18:21:05 UTC
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?
Comment 21 Chris Wilson 2014-06-18 21:28:22 UTC
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.
Comment 22 b3nmore 2014-06-18 21:35:39 UTC
(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).
Comment 23 Chris Wilson 2014-06-19 07:33:19 UTC
(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.)
Comment 24 b3nmore 2014-06-19 09:30:09 UTC
(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.
Comment 25 Chris Wilson 2014-06-19 10:52:59 UTC
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?
Comment 26 b3nmore 2014-06-19 10:53:48 UTC
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?
Comment 27 Chris Wilson 2014-06-19 10:58:17 UTC
(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.
Comment 28 b3nmore 2014-06-19 11:25:10 UTC
(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.
Comment 29 Chris Wilson 2014-06-19 11:31:07 UTC
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>
Comment 30 b3nmore 2014-06-19 12:25:58 UTC
(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.
Comment 31 Chris Wilson 2014-06-20 14:13:36 UTC
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.
Comment 32 Chris Wilson 2014-06-20 19:08:32 UTC
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.
Comment 33 b3nmore 2014-06-20 21:37:20 UTC
(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.
Comment 34 Chris Wilson 2014-06-23 09:50:14 UTC
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.