Hi, the current git head 79309dd55f20098e12ead5427c811f237d5592fa results in render glitches, I guess bad flushes are in game. I got corruption resulted in two ways: 1) old window content is in place of new windows 2) text is missing and it is displayed after some time (several seconds) the offending commit seems to be: e7b31b6d0a32f76db4a8aef64c77d4afe808fb6c HW is Lenovo T420 - SNB graphics, driver configured with --enable-snb --disable-uxa. -- Lukas Hejtmanek
Let's cover the basics by attaching you Xorg.0.log (basically just to confirm your hw details and to see which kernel we have). What WM/compositing mode are you using?
Created attachment 63803 [details] xorg log
(In reply to comment #1) > Let's cover the basics by attaching you Xorg.0.log (basically just to confirm > your hw details and to see which kernel we have). attached. > What WM/compositing mode are you using? I use XFCE environment with Openbox WM. I believe that no compositing is in place. Moreover, I noticed that notification icons flash on updates/animations in notification area, this is unrelated to the commit I mentioned, I did not track this down. Last good version I am aware of was 2.18.0-188-gdd093ea. -- Lukas Hejtmanek
Ok, and are you seeing this with any programs in particular? I haven't yet spotted any corruption, so I'm looking for a few clues as to how to reproduce. If you can also take a few moments to compile with --enable-debug just to see if the assertions catch the buggy path, that would be very useful. If you are able to find an easy way to reproduce, please --enable-debug=full and attach the log file.
This is log (enable-debug=full) with typical usage. But render glitch did not occur. So I try again just with enable-debug. http://www.fi.muni.cz/~xhejtman/Xorg.0.log.old.bz2 (75MB) -- Lukas Hejtmanek
Thanks for the debug log. Looks like you have a complex interplay of rendering techniques going on - so much for narrowing down the likely paths! :) Looks like I'm just going to have to think instead...
Ok, found something that could match your description that was made worse by e7b31b6: commit c32bb286dc9a489232030f6abe9076411fbcecfd Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 5 03:18:12 2012 +0100 sna: Make sure damage is flushed to the CPU bo before use Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> So it the problem still as prevalent on HEAD?
(In reply to comment #7) > Ok, found something that could match your description that was made worse by > e7b31b6: I give it a try and let you know. I just reproduced it again without this patch but with enable-debug. Unfortunately, no assertions are hit.
Is your render corruption limited to text? I've spotted an issue where lowriter is redrawing its gtk+ text elements (menus and statusbar) above over windows (i.e. the clip is being dropped somewhere).
If it is text related, then commit cd2dd3016e0834d1636aa96511608022a4cdbcd1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 5 19:58:54 2012 +0100 sna: Fix clipping of glyphs-to-dst for partially obscurred windows might be relevant as well.
I'm pretty sure the icon flashing is going to be a front buffer rendering artifact. I have to balance between keeping the GPU busy and building up a large batch for efficiency. So I use a mix of emitting a batch if ever the GPU is idle and emitting at least once a vblank. However, in the past the flash was because the icons were being modified across multiple batches with a significant (> 1 vblank interval). This is partly because the icons are being client-side rendered onto a GPU buffer (i.e. the client fills the background using the GPU, reads back the pixmap and then puts the icon image over top). Once we have the render corruption solved, I'd like to find a small example with flashing icons so that I can examine its debug logs.
(In reply to comment #11) > Once we have the render corruption solved, I'd like > to find a small example with flashing icons so that I can examine its debug > logs. I think I could provide full-debug for isolated icon flashing (not necessarily flashing but I guess that render path is still the same). Maybe relevant info, the flasing is not constant but it flashes more or less probably based on GPU load balancer as you stated. -- Lukas Hejtmanek
(In reply to comment #9) > Is your render corruption limited to text? I've spotted an issue where lowriter > is redrawing its gtk+ text elements (menus and statusbar) above over windows > (i.e. the clip is being dropped somewhere). I think they are mostly text related. I am not aware of any non-text glitches. However, text related - it means background including - i.e., text is mis-rendered including its background. I don't know whether this is this case or not. Anyway, I'm running flush fix and so far it seems to be OK, I will do more testing. Btw, render glitches are getting worse with uptime. The higher uptime, the more glitches and basically no glitches just after boot. -- Lukas Hejtmanek
How are we faring with the corruption? Is that gone now?
(In reply to comment #14) > How are we faring with the corruption? Is that gone now? Yes, it seems to be gone. Do you want me to create another bug report for flashing notification icons? -- Lukas Hejtmanek
This will do fine, retitling for clarity.
(In reply to comment #16) > This will do fine, retitling for clarity. So what should I provide for this issue?
A minimal test case or method to reproduce would be best. Failing that a debug=full log of a session where you recreate the conditions (if not necessarily the flash due to the timing effect of the debugging).
Ok, my test case is as follows: X :1.0 & export DISPLAY=:1.0 xfce4-panel & (it is OK to have just plain panel only with notification area) sleep 10; psi-plus (jabber client, default configuration) and just let you someone send you a message, icon in notification area should be animated. Anyway, I upload debug-log=full in this case. I believe, fast debugs at the end of the log result directly from icon animation..
Created attachment 64327 [details] xorg debug log
Ok, for starters this is not the same problem as last time - that we redrew the elements across multiple batches spaced over several vblanks. As far as I can tell, we don't use deferred batches in that sequence - the GPU is never busy enough to warrant it. I'll look over the debug log some more and see if I can make sense of it, and try and reproduce the issue once I've cleared up some of the more perplexing corruption reports. Thanks.
Note to self, I want you check after we land userptr in the kernel.
commit 3e9120d73c6f0c0e06b617da91cc2edce4434bc3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Dec 10 11:05:16 2012 +0000 sna: Immediately flush a split batch If we submit a batch early (for example if the GPU is idle), then submit whatever else the client drew immediately upon completion of its blockhandler. This is required to prevent flashing due to visible delay between the clear at the start of the cycle and then the overdraw later. References: https://bugs.freedesktop.org/show_bug.cgi?id=51718 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> That's as good as I can make it, I believe.
Yes, it seems to be a lot better. Thanks.
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.