Bug 50477

Created attachment 62244 [details]
Czech text looks more similar to China now ;)

Created attachment 62245 [details]
Thunderbird with artifacts

Please do remember to attach a dmesg and Xorg.log each time, so that we have a description of your system available.

Created attachment 62257 [details]
kernel boot log

Created attachment 62258 [details]
Xorg.0.log

Created attachment 62259 [details]
xorg.conf

I'm not sure what is the reason for China text style - it might be that system without running some glory gnome daemon is now unable to make a proper rendering, since I do not see such bad text being rendered in my normal gnome with openbox session.  But still one could easily notice, that Thunderbird has weird lines shown in 'Write a new message' and its icon.

Here are some options I'm using with 'valgrind'

MALLOC="--malloc-fill=aa"
FREE="--free-fill=21"
TRACKFD="--track-fds=yes"
STACK="--max-stackframe=300000"
EXTRAS="--read-var-info=yes"
LOGFILE="--log-file=/tmp/valglog.$SUFFIX"
TIMESTAMP="--time-stamp=yes"
LEAKCHECK="--leak-check=yes"
LEAKCHECK="--leak-check=full --track-origins=yes"
CALLERS="--num-callers=40"

Created attachment 62260 [details] [review]
Flush scanout even when idle

Looks to be a flushing issue, which can be quite pronounced on 965g. Looks like the rearranged work queues could easily defeat the scanout flush. So can you try the attached patch?

Created attachment 62261 [details] [review]
Flush scanout even when idle

Now even compile tested.

Created attachment 62262 [details] [review]
Flush scanout even when idle

And now with git add. Ok, ok, I'm going to get my coffee.

Created attachment 62265 [details]
Pidgin with patch

Ok there seems to be some improvement.
But still one can now easily see a lot of font rendering bugs.

I've also wanted to try thunderbird - but now the machine almost instantly locks as explored in bug 50393 - so I'll enhance info there about it.

After the valgrind fix and/or without valgrind, do you still see the same issues?

(In reply to comment #12)
> After the valgrind fix and/or without valgrind, do you still see the same
> issues?


With valgrind upgrade China-like text is fixed.
However I'm still able to get the artifacts from the first attachment 1 [details] [review].

What's the environment for the remaining no-redraw issue? Compositing on/off, which WM, which themes?

(In reply to comment #14)
> What's the environment for the remaining no-redraw issue? Compositing on/off,
> which WM, which themes?

I'm running  openbox-gnome-shell.

So I guess compositing is Off.

I've opaque window movement.

And I'm still able to get them with 1dafb4777f8378c87f34feae667582498220204c.

This may just be related:

commit ab3b7fe31b5a9d7924e959f21d29c4f7352ec8cb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 13 10:35:14 2012 +0100

    sna: Only reuse a write buffer if all external references have been dropped
    
    This avoids the unhappy situation of overwriting an upload buffer that
    we intend to use for a fallback.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

 (In reply to comment #16)
> This may just be related:
> 
> commit ab3b7fe31b5a9d7924e959f21d29c4f7352ec8cb
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Jun 13 10:35:14 2012 +0100
> 
>     sna: Only reuse a write buffer if all external references have been dropped


Hmm - no I'm still able to get those tiny lines even with this commit

Wow, that took a long time to finally reproduce it.

The key was your hint that the pixmap migration path was suspect. I found the shaped corners of opera (which is a pure client side renderer) was the most likely to reproduce the issue if I slowly moved it across a pure server (GPU-only) rendered window.

commit 75e9eeca7e998b1ee3f8b0df780adae1b9e5b408
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jun 18 16:39:20 2012 +0100

    sna: Remove overlapping CPU damage when operating inplace on the GPU
    
    Otherwise we gradually introduce garbage into the picture.
    
    Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50477
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Zdenek, thanks a lot for all the feedback.

While the patch 75e9eeca7e998b1ee3f8b0df780adae1b9e5b408 helped in a way, it's not completely trival to get those unwanted pixel - it's still possible to get them - especially in pidgins's tabs it's sometime possible.

I'd have said it's like some part are now missing proper redraw (attaching pic) - or the background color for redraw is wrong. Also gnome-terminal shows some defect, but it's getting harder to get them.

Created attachment 63189 [details]
pidgin broken redraw

different color around i.e. close button

I've pushed a set of assertions for catching further instances of the overlapping damage bug, under  --enable-debug=pixmap. That would be useful to test in your thunderbird + pidgin scenario.

Ok, can reproduce the thunderbird + pidgin artifact almost at will now. Looks to be in sna_copy_boxes().

After much poking around, this is looking more like #define FORCE_INPLACE 1! :|

Oh my. That kind of explains why it was so difficult to hit, it required a write to a busy upload buffer.

commit 291b3c4367b455bfc5a772f8caaeee73f36d826a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jun 18 23:43:00 2012 +0100

    sna: Align upload buffers to 128
    
    This seems to be a restriction (observed on 965gm at least) that we
    have incoherent sampler cache if we write within 128 bytes of a busy
    buffer. This is either due to a restriction on neighbouring cachelines
    (like the earlier BLT limitations) or an effect of sampler prefetch.
    
    Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=50477
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

So I think that should fix the gnome-terminal glyph corruption as well as the thunderbird dragged over pidgin.

I don't see the differing bg behind buttons/images, so can you confirm that after updating?

Created attachment 63209 [details]
New kind of err

So I've retested with b0b2d3c9663c29e9844aef1608416ae40c194b55
And there is some change in the error produced now when i.e. thunderbird windows is moved over the active tab in pidgin window - now I get differently colorized stripes. When the window gets focus, pidgin redraws tab label thus only bottom of stripe are left there until full expose arrives.

So the patch fixed something, but still few issues are there to be found. Wondering if prior those fixes they could have resulted in some GPU hangs - since for a few days I've not had them.

Created attachment 63210 [details]
Different error from gnome-terminal

Also gnome-terminal now shows different error - there are no black dots,
but rather thicker white lines (picture is doubled in size).

Assuming those thin white lines in shadow will be possible fixed by your Cairo commit, but thick breaks in gray lines are error from driver.

Standard question: anything changed in your test setup? Still openbox + adwaita + thunderbird + pidgin + gnome-terminal?

(In reply to comment #27)
> Standard question: anything changed in your test setup? Still openbox + adwaita
> + thunderbird + pidgin + gnome-terminal?

Well, I do some updates of my rawhide box:

openbox-3.5.0-6.fc18.x86_64
gnome-terminal-3.4.1.1-1.fc17.x86_64
pidgin-2.9.0-2.fc16.x86_64  (keeping an old version, new one failed with audio)
thunderbird-13.0.1-1.fc18.x86_64   (was updated)
adwaita-gtk3-theme-3.5.2-1.fc18.x86_64   (unsure how it relates to openbox)


But looking at yum history new Xorg has arrived:
xorg-x11-server-Xorg-1.12.2-2.fc18.x86_64

for completeness using git drm: 
9e0026d35c56374b53a0b3837e24412bc9a4d8c9

But IMHO I do not think updates are related here - it's still something in driver, since UXA is OK.

Ok, so that was embarrassing :)

commit 4acf727941a37651f672db3774281a437940c540
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jun 19 10:20:54 2012 +0100

    sna: Initialize the color value for fallback unaligned boxes
    
    Reported-by:Zdenek Kabelac <zkabelac@redhat.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=5047
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Great, from quick test it appears to me  YOU MADE IT :)

So except for Cairo bug in gnome-terminal shadow I'm not able to spot some rendering bugs now.