Created attachment 70592 [details] SNA Rendering With SNA enabled my screen has some minor rendering corruptions. These are not visible with UXA
Created attachment 70593 [details] UXA Rendering
Created attachment 70594 [details] Xorg.0.log
Try turning off desktop effects as a simple test for a known Damage bug.
Ok that helps, sorry for the duplicate i did not find!
Do you mind giving me a status update?
Still visible. But it did get better imho! intel driver: 2.21.12 your workaround from comment 3 still works! thanks!
The noted corruptions are gone. But there are still other minor corruptions.
Created attachment 84798 [details] Leftover rendering corruptions
Additional Notes: intel driver: 2.21.15 Kernel: 3.11.0-rc7+ libdrm: 2.4.46 Mesa: 9.3-devel
If we ignore that Damage is not tracking certain operations.... There have been a number of damage related and Ivybridge related fixes since, so it is well worth retesting.
I can still reproduce this, but unlike earlier i have to try really hard! That may as well be kde related!
Created attachment 93186 [details] 2.99.908 Regression After i had noticed you released 908 today, i rechecked if the bug was there. it is, but while wanting to upload another picture for the leftover rendering corruption i noticed a grave regression. This is not reproducible with 907!
Already doing a brown paper bag release. :(
Embarrassment release pushed.
Created attachment 93195 [details] 2.99.909 minor Regression Yo may put away the brown paper bag (Thanks for the quick fix!). But nevertheless, this is the pedantic thread ;-) , so i have something new for you! Note the black border around one of the icons in the list. This is while the mouse cursor hovers over it. This again is not reproducible with 907!
Ugh, found it in the end: commit 853588ad5be9407d2123f6055458ca84e72b8eb9 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Feb 1 21:55:09 2014 +0000 sna: If IGNORE_CPU is not set we must mark the move as MOVE_READ Logic reversal in discarding CPU damage. An old bug revealed by the more aggressive attempts to discard CPU damage. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Confirmed, the black border is gone! Thanks!
Can't reproduce the remaining rendering corruption from Comment #8 with KDE 4.13, looks like the driver was not the problem in the end. Thanks!
Created attachment 96901 [details] 2.99.911 After several days without it, today the damage bug came back :/
Do you have a screenshot? There have been a few mesa regressions that affect KDE in particular, which might account for the reoccurrence.
attachment 96901 [details] from Comment #19 is from a few minutes ago
Sorry about missing the updated image, I just overlooked it in the email. Are you using the raster backend for Qt?
No problem :-) Yes, I'm using the Raster Backend with OpenGL 3.1.
Master now has a fix for a PutImage regression in 2.99.911, which was hit by Qt's Raster engine.
Ok, testing master and will report back. Thanks!
Still reproduceable with Head of Master, sorry! Don't know if this is important, but I'm using Mesa 10.2-devel versions, following Mesa Master closely as well.
Whilst there are some pretty severe regressions in mesa-10.1+ that affect KDE, your screenshot doesn't look like one of them. Have you tried switching between different engines for compositing and rendering?
Give the fact that KDE is not lying to me about the backends and the OpenGL Versions, the bug persists with both Native/Raster with any given OGL Versions (3.1, 2.0, 1.2). That makes me wonder if KDE is really switching it.
One thing that would help is knowing whether the XRender Desktop Effects backend is also susceptible. Then perhaps whether mesa-9 shows the same errors, or xorg-1.14.
It really does, hmm ok, lets see where I can get a Mesa and a XServer 1.14
Created attachment 97167 [details] Corruptions with Mesa 9.2.3 and XServer 1.14.3.901 As you can see, it has not helped: Mesa 9.2.3 XServer 1.14.3.901 xf86-video-intel 2.99.911+ (git snapshot as of yesterday evening)
Hmm, I had hopes that it was a fbconfig selection issue. What are the exact steps to reproducing this?
Steps to reproduce: 1) Log in with Desktop Effects activated 2) Click at the Networkmanager/nm Applet (does work with Calender/Notifications as well) 3) Click somewhere at the Desktop to hide the Applet 4) now you should see the Corruption
Or not. :| Would it be possible for you to bisect what triggered the regression this time? Presuming we can find a point in time where it did work.
Bisecting is not the problem, but finding a good starting point will is. Anyway lets see what i can do.
Tried to find a good commit, but have failed miserably :/. The good state noted in Comment 18 was 2.99.911 or 910, but both are bad now. I'm uncertain if it is the driver, Mesa or KDE and I'm not able to reproduce the good state again.
Created attachment 97202 [details] Fedora Live KDE Ok, a final try for a reproduce able bug: 1) Start a new KDE, here Fedora KDE Live: http://dl.fedoraproject.org/pub/fedora/linux/updates/20/Live/x86_64/Fedora-Live-KDE-x86_64-20-20140407.iso 2) start Systemsettings, choose "Desktop Effects" 3) Within the General Tab set Animation Speed to Very Fast (apply) 4) Within the Advanced Tab choose OpenGL 3.1 (apply) 5) Open the Network Widget, click somewhere at the desktop to hide the widget again -> now you finally should see it (tried several times, and works always)
For me, the setting that made the difference in the end was "Tearing Prevention (VSync): None"
I am able to reproduce the persistent shadow with UXA, SNA and software rendering. I think this might not be a ddx bug.
Hmm ok, some final notes about tearing prevention from my side: None/Only when Cheap (update of major screen regions) -> shadow bug Full Scene Repaints -> no bug at all Re-use screen content -> much worse, windows are not redrawn at all Leaving this bug open, but your conclusion sounds right, so you are free to close. Thanks!
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/14.
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.