Created attachment 70592 [details]
With SNA enabled my screen has some minor rendering corruptions. These are not visible with UXA
Created attachment 70593 [details]
Created attachment 70594 [details]
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!
The noted corruptions are gone. But there are still other minor corruptions.
Created attachment 84798 [details]
Leftover rendering corruptions
intel driver: 2.21.15
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]
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:
Author: Chris Wilson <email@example.com>
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 <firstname.lastname@example.org>
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]
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 18.104.22.1681
As you can see, it has not helped:
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:
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.
-- 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.