I have SNB chip, with git driver 5913c90967091124e7c7b262782f0e99cf400eab, 3.1-rc9 kernel. I noticed that refresh of notification area or e.g., xosview refresh is linked with flashing. Looks like background exposing is synced with vertical refresh so it is visible and disturbing. This behaviour is more noticable at fresh start of system (after boot). If I run my desktop for several days, the problem disappears. I use SNA acceleration. Xserver's version is 1.10.4. I am able to run tests if needed. PS: if I do not respond within a day, please kick me by mail, it happened before that I did not receive e-mail notifications of bug report responses.
The first suggestion is to try commit c5414ec992d935e10156a2b513d5ec2dded2f689 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Oct 2 12:02:41 2011 +0100 sna: Use BLT operations to avoid fallbacks in core glyph rendering Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (i.e. update to current master) which should address the culprit for xosview. If you can find further examples of failure, please let me know.
(In reply to comment #1) > The first suggestion is to try > > commit c5414ec992d935e10156a2b513d5ec2dded2f689 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Sun Oct 2 12:02:41 2011 +0100 > > sna: Use BLT operations to avoid fallbacks in core glyph rendering > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > (i.e. update to current master) which should address the culprit for xosview. > If you can find further examples of failure, please let me know. I updated driver to the commit 823a4272c50247482428a16cb08741bf87a302ea. xosview seems to be OK. notification area from xfce4 is still flashing.
(In reply to comment #2) > (In reply to comment #1) > > The first suggestion is to try > > > > commit c5414ec992d935e10156a2b513d5ec2dded2f689 > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > Date: Sun Oct 2 12:02:41 2011 +0100 > > > > sna: Use BLT operations to avoid fallbacks in core glyph rendering > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > > > (i.e. update to current master) which should address the culprit for xosview. > > If you can find further examples of failure, please let me know. > > I updated driver to the commit 823a4272c50247482428a16cb08741bf87a302ea. > > xosview seems to be OK. notification area from xfce4 is still flashing. I am running: commit 823a4272c50247482428a16cb08741bf87a302ea Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Oct 11 13:51:41 2011 +0100 sna/gen3: Avoid RENDER/BLT context switch for fill boxes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> and I got huge screen corruption. The first bad commit is: commit c5414ec992d935e10156a2b513d5ec2dded2f689 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Oct 2 12:02:41 2011 +0100 sna: Use BLT operations to avoid fallbacks in core glyph rendering Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 52294 [details] Render issue
The corruption was caused by: commit b7fd6906c41e328649b97e16c42848a39f6e48f8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 13 17:46:48 2011 +0100 sna/accel: Actually apply the clip to the glyph extents References: https://bugs.freedesktop.org/show_bug.cgi?id=41718 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> But I still need to investigate xfce4 to see which fallback is being hit.
(In reply to comment #5) > The corruption was caused by: > > commit b7fd6906c41e328649b97e16c42848a39f6e48f8 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Oct 13 17:46:48 2011 +0100 > > sna/accel: Actually apply the clip to the glyph extents > > References: https://bugs.freedesktop.org/show_bug.cgi?id=41718 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > But I still need to investigate xfce4 to see which fallback is being hit. OK, I run more tests with the current git head. If it is easy to debug fallbacks, I can test it as well and provide log. However, I had to switch back to nvida as Intel does not resume from ram :(
Is there an easy way to trigger the issue with xfce4's notification area? For example "notify-send help!"?
(In reply to comment #7) > Is there an easy way to trigger the issue with xfce4's notification area? For > example "notify-send help!"? no, it is a different notification area - it's the one in xfce4 panel where various icons reside. e.g., psi (instant messaging client) is flashing most visibly.
(In reply to comment #5) > The corruption was caused by: > > commit b7fd6906c41e328649b97e16c42848a39f6e48f8 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Oct 13 17:46:48 2011 +0100 > > sna/accel: Actually apply the clip to the glyph extents > > References: https://bugs.freedesktop.org/show_bug.cgi?id=41718 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > But I still need to investigate xfce4 to see which fallback is being hit. Hmm, the current git head makes xosview flashing again.. :( But no screen corruption happens.
(In reply to comment #9) > (In reply to comment #5) > > The corruption was caused by: > > > > commit b7fd6906c41e328649b97e16c42848a39f6e48f8 > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > Date: Thu Oct 13 17:46:48 2011 +0100 > > > > sna/accel: Actually apply the clip to the glyph extents > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=41718 > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > > > But I still need to investigate xfce4 to see which fallback is being hit. > > Hmm, the current git head makes xosview flashing again.. :( But no screen > corruption happens. I meant commit# b7fd6906c41e328649b97e16c42848a39f6e48f8
Created attachment 52492 [details] blinking example If you need a simple test-case to reproduce the blinking icon issue, could you try with this one? Chris - I guess you can reproduce the issue with the same .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml as Lukas's one. Just do a script which does: #!/bin/sh (./blink.py &)& startxfce4 run it with 'xinit ./script.sh', and it should got to xfce4 environment with blinking icon in place.
Lukas - could you attach your .config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml file so we could reproduce your environment? Thanks!
So it is in the panel status tray. That's presumably rendered as a GTK icon which if memory serves will be client side compositing of the icon with SHM transport. The issue is then the same, GTK will render the background, call GetImage to copy that over to itself, composite the icon, then PutImage it back. The PutImage will be delayed until the next flush, incurring a potential flash. If I am correct, that really is GTK being dumb and avoiding hw acceleration ftl.
Created attachment 52516 [details] config file
I've tweaked the heuristics on when to migrate the pixmap onto the GPU to cater for the case of rendering icons. Can you please test with master and see how it performs? commit 5515f75647bb148d9e720dcc4713a93b59ffbd49 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Oct 19 13:49:55 2011 +0100 sna: Enlarge the minimum pixmap size to migrate for Render This is to workaround a ping-pong issue involving small icons. The horrible sequence of operations appears to use a tiled FillRect to copy from the scanout onto to a temporary pixmap, which causes us to readback from the scanout. We are destined to hit the fallback path there anyway until we implement stippling... References: https://bugs.freedesktop.org/show_bug.cgi?id=41718 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #15) > I've tweaked the heuristics on when to migrate the pixmap onto the GPU to cater > for the case of rendering icons. Can you please test with master and see how it > performs? > > commit 5515f75647bb148d9e720dcc4713a93b59ffbd49 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Wed Oct 19 13:49:55 2011 +0100 > > sna: Enlarge the minimum pixmap size to migrate for Render > > This is to workaround a ping-pong issue involving small icons. The > horrible sequence of operations appears to use a tiled FillRect to copy > from the scanout onto to a temporary pixmap, which causes us to > readback from the scanout. We are destined to hit the fallback path there > anyway until we implement stippling... > > References: https://bugs.freedesktop.org/show_bug.cgi?id=41718 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Well, it is not so obvious, but animated icon from psi (instant messaging) is still flashing. Also, xosview is still flashing as well. I collected DEBUG_GLYPHS and DEBUG_RENDER messages, don't know whether they are useful or not. I was unable to collect debug messages with flashing psi icon. When I tried to go online, I got an assertion from kgem (bo is not bussy or something like that). This happened three times per three tries, looks like not an accident. Maybe, I my removing NDEBUG ifdef around validate_partials was wrong but I got unresolved symbol otherwise.
(In reply to comment #15) > I've tweaked the heuristics on when to migrate the pixmap onto the GPU to cater > for the case of rendering icons. Can you please test with master and see how it > performs? > > commit 5515f75647bb148d9e720dcc4713a93b59ffbd49 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Wed Oct 19 13:49:55 2011 +0100 > > sna: Enlarge the minimum pixmap size to migrate for Render > > This is to workaround a ping-pong issue involving small icons. The > horrible sequence of operations appears to use a tiled FillRect to copy > from the scanout onto to a temporary pixmap, which causes us to > readback from the scanout. We are destined to hit the fallback path there > anyway until we implement stippling... > > References: https://bugs.freedesktop.org/show_bug.cgi?id=41718 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Well, it is not so obvious, but animated icon from psi (instant messaging) is still flashing. Also, xosview is still flashing as well. I collected DEBUG_GLYPHS and DEBUG_RENDER messages, don't know whether they are useful or not. I was unable to collect debug messages with flashing psi icon. When I tried to go online, I got an assertion from kgem (bo is not bussy or something like that). This happened three times per three tries, looks like not an accident. Maybe, I my removing NDEBUG ifdef around validate_partials was wrong but I got unresolved symbol otherwise. Debug log is here, I was unable to put it as an attachement :( http://www.fi.muni.cz/~xhejtman/Xorg.0.log
I think I have the flashing under control now, please can you test tip. In particular, the combination of commit 676cb4e38dc381b2ef4fb092b66db80687aa5013 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Nov 4 23:30:09 2011 +0000 sna: Run the deferred flush at vrefresh This helps to reduce the perceived jerkiness of the redraw. Reported-by: Clemens Eisserer <linuxhippy@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42413 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> and commit 7e8c9a5b8b1625fdfe885740c36da3f4c1373ee6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 2 14:02:56 2011 +0000 sna: Submit the batch on the next blockhander if operation overflows If an operation overflows from one batch into another, we submit the complete batch and begin a new. That new batch will not be submitted unless it is filled or on the next delayed flush update. This can cause a flicker as a large operation is broken up, such as performing a CopyArea through a Clipmask. So if we submit a full batch during a flush interval, immediately flush any partial batch at the next blockhandler. This stops rude Santa flashing Rudolf in xsnow! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #18) > I think I have the flashing under control now, please can you test tip. yes, all the things are not flashing any more, so this seems to be resolved. thanks. I got still screen corruption probably because of rc6, but this is tracked elsewhere..
Lukas, thanks for checking. Please do keep poking us on your other bugs as well. :)
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.