Created attachment 62243 [details] Pidgin with artifacts From time to time I'm noticing some visual artifacts on my machine when using SNA driver. I'm attaching picture how I could relatively easily reproduce them on my machine. sna driver commit: 264d1b1e1fb368f7845a8112bfa2ad2224acabd9 Originally I wanted to report only case where pidgin window is left with some unrefreshed small lines in the red circle (attached). The effect has been achieved via slower movement of thunderbird window (black arrow). It's also possible the 'refresh' routine isn't the best one in pidgin Qt application, but I've seen several times similar things with gnome-terminal - but it's not so easy to get those captured - pidgin could be trapped within minute. However then I've noticed the when I start empty Xorg server in valgrind - I'm getting even more 'impressive' pictures. It's worth to note I'm not seeing such drastic picture with regular Xserver run.
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.
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.