Bug 51718

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.