From https://bugzilla.gnome.org/show_bug.cgi?id=733397: gnome-shell 3.12.2 mutter 3.12.2 clutter 1.18.2 cogl 1.18.2 mesa 10.2.3 xorg-server 1.16.0 xf86-video-intel 2.99.912-246-g4ae346e linux 3.15.6 Sometimes the screen isn't updated when it should be. I've seen this happen when scrolling pagewise using the keyboard in gnome-terminal, gedit or Firefox. The previous content is retained until something else (such as another scroll, moving the window or visible activity in another window) causes an update. This started happening since upgrading xorg-server from 1.15.2 to 1.16.0, which consequently enabled DRI3. It happens in both mutter and gnome-shell. Disabling DRI3 for the compositor using LIBGL_DRI3_DISABLE=1 makes the problem disappear. --- When switching from SNA to UXA or Glamor, the compositor won't even start without LIBGL_DRI3_DISABLE. It immediately gets an X BadAlloc error. This is on a Thinkpad X220 (SNB).
Have you implemented fences before reading from DRI3 objects yet?
(In reply to comment #1) > Have you implemented fences before reading from DRI3 objects yet? No idea whom you mean by "you" but here is the IRC discussion from yesterday: <drago01> keithp: hi, around? <keithp> drago01: just for a few minutes <drago01> keithp: https://bugzilla.gnome.org/show_bug.cgi?id=733397 <drago01> keithp: seems like with dri3 we no longer have seralized x/gl drawing <keithp> could be the video driver's fault <drago01> keithp: so is there any way to fix it without x sync fences (that aren't implemented iirc) <keithp> uh, x sync fences are required for DRI3 <drago01> does the driver / xserver support them? <drago01> (no xserver 1.16 setup here to check) <keithp> the mesa driver expects them, so it depends on whether the 2D driver does them correctly <keithp> if there aren't sync fences, DRI3 won't work at all <keithp> might be good to try UXA vs SNA and see if there's a difference <keithp> in the intel driver <keithp> I've only ever tested with UXA <keithp> and gnome-shell was working last time I tried <keithp> (which was a while ago) <drago01> by x fences I mean GL_EXT_x11_sync_object which we have patches for but not applied yet <keithp> oh, we "shouldn't" need those for intel as the 2D driver should be flushing stuff out before delivering damage events <drago01> ok <keithp> no difference from DRI2 <drago01> ok will ask the reporter to test uxa (or glamor?) <keithp> glamor, not so much <keithp> uxa is a better bet <drago01> ok <drago01> keithp: <drago01> <heftig> drago01: with glamor or uxa, mutter won't even start without LIBGL_DRI3_DISABLE <drago01> <heftig> it will immediately get a X BadAlloc error <drago01> (asked him to just file a driver bug for now) <keithp> sounds like something is seriously busted; gnome works fine here <drago01> Jasper has seen some similar redrawing issues too <Jasper> drago01, keithp: it seems like damage events are sent before the pixmap is actually drawn to. <drago01> Jasper: with uxa too? <Jasper> drago01, haven't tested with UXA
DRI3 relies on explicit fencing. '<keithp> oh, we "shouldn't" need those for intel as the 2D driver should be flushing stuff out before delivering damage events' is wrong, per usual.
(In reply to comment #3) > DRI3 relies on explicit fencing. > > '<keithp> oh, we "shouldn't" need those for intel as the 2D driver should be > flushing stuff out before delivering damage events' > > is wrong, per usual. You mean we need fencing in the compositor or can this be done inside the 3D driver? As for doing it in the compositor mesa does not seem to implement GL_EXT_x11_sync_object.
(In reply to comment #4) > (In reply to comment #3) > > DRI3 relies on explicit fencing. > > > > '<keithp> oh, we "shouldn't" need those for intel as the 2D driver should be > > flushing stuff out before delivering damage events' > > > > is wrong, per usual. > > You mean we need fencing in the compositor or can this be done inside the 3D > driver? As for doing it in the compositor mesa does not seem to implement > GL_EXT_x11_sync_object. s/3D driver/2D driver/
It could be completely neutered inside X by removing the explicit sync model in DRI3.
Created attachment 103262 [details] [review] Neuter explicit fencing
*** Bug 79949 has been marked as a duplicate of this bug. ***
Had issues with refresh for GTK application after updating to xorg 1.16 with DRI3 enabled. After applying this patch to xf86-video-intel-2.99.912 issue is gone. Thanks!
The patch also resolves my issues.
When applying the workaround: < RAOF> mlankhorst: ~ppa10 works fine, ta. < RAOF> mlankhorst: And when I say “works fine” what I actually mean “is no longer frustratingly buggy, now merely sometimes and temporarily leaves stale rendering around” < mlankhorst> RAOF: yeah try with dri 2? < RAOF> Yeah, DRI2 worked fine. < RAOF> To be honest, the stale rendering in DRI3 is now only really noticeable because I'm looking for it.
*** Bug 81401 has been marked as a duplicate of this bug. ***
*** Bug 80613 has been marked as a duplicate of this bug. ***
Hmm, so bug #80613 (duplicate of this one) mentions that the issues always appear after a suspens/resume cycle. I was wondering if my bug #81548 is also a consequence of this fencing issues. Anyway, is there going to be a permanent solution to this problem? Seems like the patch by Chris hasn't landed upstream, so I guess it's considered more like a workaround at the moment.
I'm having a hard time wrapping my head around this bug. It seems to entail that everyone who installs a reasonably recent (Xorg >= 1.16, video-intel >= 2.99) system with an otherwise unchanged configuration will get an unusable system by default. (Unusable in the sense of missing screen updates left and right.) What I'm having trouble understanding is the combination of the following three: - This seems kind of severe, as I described above--unless I'm misunderstanding something. - There seems to be a bit of communication breakdown, as Chris called Keith "wrong as usual" (again, unless I'm misreading something here...) - Nobody has paid attention to this since July/August. Again, I'm an outsider and don't want to cause grief, but if someone could explain what the situation is, I'd very much appreciate it. Thanks!
We lose. Mesa is not going to gain support for interclient fencing anytime soon. commit fc984e8953d61901b255422c8f56eb79a2dd2a28 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 22 08:38:42 2014 +0100 sna/dri3: Mesa relies upon implicit fences for X/Compositor synchronisation The decision has been made that DRI3/intel shall continue with DRI2-style implicit fencing for synchronisation between X and clients using pixmaps as texture sources. (The other way around uses explicit fencing!) References: https://bugs.freedesktop.org/show_bug.cgi?id=81551 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
*** Bug 83101 has been marked as a duplicate of this bug. ***
*** Bug 84108 has been marked as a duplicate of this bug. ***
fwiw the overhead from implicit fencing is ~40% (on byt, bdw-u) in CPU-bound rendering workloads (as the implicit fencing prevents the driver from batching up rendering commands).
Okay - So serious nube. I see that a patch is posted for this bug, but as a nube, have absolutely no idea how to apply it. If someone would be so kind to help me out...... William
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.