[gen4 sna] Font corruption

[Jonathan Thomas]

After enabling the SNA acceleration method and rebooting, I noticed that graphical glitches appeared in the letters on Chromium's tab bar during the mouse hover animation. I've attached a screenshot illustrating this, particularly with the letter "g" in the screenshot.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: xorg 1:7.7+1ubuntu4
ProcVersionSignature: Ubuntu 3.7.0-7.15-generic 3.7.0
Uname: Linux 3.7.0-7-generic x86_64
ApportVersion: 2.8-0ubuntu1
Architecture: amd64
Date: Thu Jan 10 16:00:55 2013
InstallationDate: Installed on 2012-09-24 (107 days ago)
InstallationMedia: Kubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120822.2)
MarkForUpload: True
SourcePackage: xorg
UpgradeStatus: Upgraded to raring on 2012-09-25 (107 days ago)

[Joe Peterson (bx09m7e-say-zwnfzpm)]

Using the xf86-video-intel driver in SNA mode (using version 2.20.9, but I've seen it back to 2.20.7 as well - I have not tested SNA in earlier versions), chromium tabs exhibit a strange "blotchy" flickering of text/graphics as the mouse is moved over them. Note that this may vary depending on the text (or more probably the length of the text) in the tab.

I wonder if the transparent gradient/fade of the text in these tabs plays a part here.

I will attach a video screen capture of this happening. One URL that causes it is the URL of a previous bug I reported: https://bugs.freedesktop.org/show_bug.cgi?id=55484 (the tab in the video uses this one).

[From my lspci: VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)]

[Joe Peterson (bx09m7e-say-zwnfzpm)]

Created attachment 67928
Video screen capture showing the chromium tab flicker

[Chris Wilson (ickle)]

Can you please check that attached video is the correct one? mplayer doesn't complain, but doesn't show anything either.

Also can you please attach your Xorg.0.log so that I know what hardware you have, and which WM you are using (and any compositing options)?

[Joe Peterson (bx09m7e-say-zwnfzpm)]

Created attachment 67929
Video screen capture showing the chromium tab flicker

Trying this attachment again - this time specifying binary manually... the previous upload seemed to alter the file.

[Joe Peterson (bx09m7e-say-zwnfzpm)]

Created attachment 67930
Xorg.0.log file from session showing problem

[Joe Peterson (bx09m7e-say-zwnfzpm)]

I am using openbox as a WM. I have not selected any special (non-default) compositing options that I know of.

[Chris Wilson (ickle)]

What it actually looks like is that the gradient is misapplied whilst rendering the glyphs.

Can you please test with either downgrading pixman to 0.26 or compile -intel with -UHAS_PIXMAN_GLYPHS?

[Chris Wilson (ickle)]

And for an extra level of paranoia, can you also check if the error persists if you do a debug build (unoptimized, -O0) of pixman, xserver, and -intel? Having been burnt by bugs uncovered by aggressive compiler optimisations before, it helps to keep me calm to have a sanity check. ;-)

[Joe Peterson (bx09m7e-say-zwnfzpm)]

Ok, I downgraded to pixman-0.26 (which then causes -intel to be build without HAS_PIXMAN_GLYPHS). I also compiled xorg-server and -intel with -O0. However, I was unable to compile pixman with -O0, because configure failed (checking for MMX support).

The same problem persists even with the above done. Let me know if I should try anything else, or if this is enough to verify that it's not pixman...

[Chris Wilson (ickle)]

Yes, that is enough to rule out the new pixman_glyph_t routines and enough that is not some random miscompilation. Which means we^W I need to look harder.

[Chris Wilson (ickle)]

First of all lets disable acceleration of glyphs:

diff --git a/src/sna/sna_glyphs.c b/src/sna/sna_glyphs.c
index 53494e3..4e510a4 100644
--- a/src/sna/sna_glyphs.c
+++ b/src/sna/sna_glyphs.c
@@ -69,7 +69,7 @@

 #include <mipict.h>

-#define FALLBACK 0
+#define FALLBACK 1
 #define NO_GLYPH_CACHE 0
 #define NO_GLYPHS_TO_DST 0
 #define NO_GLYPHS_VIA_MASK 0

That will tell us whether the corruption occurs as we render the glyphs using the GPU or as we upload. Similarly working through each of the NO_* options thereafter would be very helpful to identify which path in particular is affected.

Secondly,

diff --git a/src/sna/gen4_render.c b/src/sna/gen4_render.c
index ceef528..f901008 100644
--- a/src/sna/gen4_render.c
+++ b/src/sna/gen4_render.c
@@ -1863,7 +1863,7 @@ gen4_composite_picture(struct sna *sna,
        if (picture->pDrawable == NULL) {
                int ret;

- if (picture->pSourcePict->type == SourcePictTypeLinear)
+ if (picture->pSourcePict->type == SourcePictTypeLinear && 0)
                        return gen4_composite_linear_init(sna, picture, channel,
                                                          x, y,
                                                          w, h,
@@ -2046,7 +2046,6 @@ check_gradient(PicturePtr picture)
 {
        switch (picture->pSourcePict->type) {
        case SourcePictTypeSolidFill:
- case SourcePictTypeLinear:
                return false;
        default:
                return true;

will confirm whether is it the gradient that is implicated in this bug.

[Joe Peterson (bx09m7e-say-zwnfzpm)]

OK, tried your suggestions - I set the following, one at a time, to 1. Here are the results:

 #define FALLBACK 0 clean
 #define NO_GLYPH_CACHE 0 clean
 #define NO_GLYPHS_TO_DST 0 clean
 #define NO_GLYPHS_VIA_MASK 0 bad
 #define NO_SMALL_MASK 0 bad
 #define NO_GLYPHS_SLOW 0 bad
 #define NO_DISCARD_MASK 0 bad

Where it says "clean", changing only this define to 1 (and leaving the rest at 0) fixed the problem. Where it says "bad", the bug still existed with only this define set to 1.

Applying the gen4_render.c patches (with all of the above unchanged at set to 0) had no effect - the bug still existed.

Let me know if this helps.

[Chris Wilson (ickle)]

Ok, we are now into the realms of a missing GPU flush, or rather a missing workaround.

Can you please try:

diff --git a/src/sna/gen4_render.c b/src/sna/gen4_render.c
index ceef528..9d298dd 100644
--- a/src/sna/gen4_render.c
+++ b/src/sna/gen4_render.c
@@ -1265,6 +1265,7 @@ gen4_emit_pipelined_pointers(struct sna *sna,
        if (key == sna->render_state.gen4.last_pipelined_pointers)
                return;

+ OUT_BATCH(MI_FLUSH | MI_INHIBIT_RENDER_CACHE_FLUSH);
        OUT_BATCH(GEN4_3DSTATE_PIPELINED_POINTERS | 5);
        OUT_BATCH(sna->render_state.gen4.vs);
        OUT_BATCH(GEN4_GS_DISABLE); /* passthrough */

with everything else back to normal.

[Joe Peterson (bx09m7e-say-zwnfzpm)]

(In reply to comment #12)
> + OUT_BATCH(MI_FLUSH | MI_INHIBIT_RENDER_CACHE_FLUSH);

Nope, bug still occurs.

[Chris Wilson (ickle)]

Hmm, ok. A more drastic patch to confirm that this is the flushing bug I think it is...

diff --git a/src/sna/gen4_render.c b/src/sna/gen4_render.c
index ceef528..5e35ff1 100644
--- a/src/sna/gen4_render.c
+++ b/src/sna/gen4_render.c
@@ -1376,7 +1376,7 @@ gen4_emit_state(struct sna *sna,
                const struct sna_composite_op *op,
                uint16_t wm_binding_table)
 {
- if (FLUSH_EVERY_VERTEX)
+ if (1||FLUSH_EVERY_VERTEX)
                OUT_BATCH(MI_FLUSH | MI_INHIBIT_RENDER_CACHE_FLUSH);

        gen4_emit_drawing_rectangle(sna, op);

[Joe Peterson (bx09m7e-say-zwnfzpm)]

(In reply to comment #14)
> Hmm, ok. A more drastic patch to confirm that this is the flushing bug I
> think it is...
> ...
> + if (1||FLUSH_EVERY_VERTEX)
> OUT_BATCH(MI_FLUSH | MI_INHIBIT_RENDER_CACHE_FLUSH);

No, sorry to say, this did not fix it.

[Chris Wilson (ickle)]

Created attachment 68731
Flush state changes

Since this sounds like a flush issue and gen5+ require flushes between certain pipelined ops, presume gen4 also needs them. Can you please test the attached patch as I've yet to reproduce this issue?

[Chris Wilson (ickle)]

Created attachment 68756
Flush state changes

[Chris Wilson (ickle)]

I've uploaded commit 257abfdabe39629fb458ed65fab11283f7518dc4
Author: Chris Wilson <email address hidden>
Date: Wed Oct 17 23:34:22 2012 +0100

    sna/gen4: Presume we need a flush upon state change similar to gen5+

    References: https://bugs.freedesktop.org/show_bug.cgi?id=55627
    References: https://bugs.freedesktop.org/show_bug.cgi?id=55500
    Signed-off-by: Chris Wilson <email address hidden>

in the hope that gen4 has the same brokenness as the later generations. Please reopen if this doesn't fix the corruption, thanks.

[Joe Peterson (bx09m7e-say-zwnfzpm)]

I tested just now with the latest git, and problem persists. Just to make sure I did this correctly, I replaced the following three files on my system with freshly-built ones:

/usr/lib/xorg/modules/drivers/intel_drv.so
/usr/lib/libI810XvMC.so.1.0.0
/usr/lib/libIntelXvMC.so.1.0.0

The other lib symlinks are, of course, there, for the last two.

[Mauro Fruet (maurofruet)]

This bug affects me too, on both the machines in which I have tried to enable the SNA option. I've tried to enable it both on GNOME and Xfce, with the same results. I attach the Xorg.0.log of one of them.
I have tried to install the git version of xf86-video-intel, but the bug persists.
I have also noticed that the bug seems to affect only chromium tabs in which the html title can not fit, as in the video posted by Joe Peterson.

[Mauro Fruet (maurofruet)]

Created attachment 69237
Xorg.0.log of the session affected by the bug

[Mauro Fruet (maurofruet)]

Chris, the bug has disappeared today after upgrading cairo on my Archlinux machine. The upgrade includes this set of patches (half of them are from yourself):
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/git_fixes.diff?h=packages/cairo
They were submitted on September 17, but they were included into the Archlinux cairo package only yesterday.

[Chris Wilson (ickle)]

Hmm, more relevant to this case is that they dropped the 'cairo-1.10.0-buggy_gradients.patch' which will impact the rendering in the tabs (and notably be about an order of magnitude faster). So it feels like the bug is still lurking.

[Joe Peterson (bx09m7e-say-zwnfzpm)]

(In reply to comment #23)
> Hmm, more relevant to this case is that they dropped the
> 'cairo-1.10.0-buggy_gradients.patch' which will impact the rendering in the
> tabs (and notably be about an order of magnitude faster). So it feels like
> the bug is still lurking.

Also, I have that cairo update from Arch as well, and although the problem looks (perhaps) less obvious, it's definitely still there.

[Mauro Fruet (maurofruet)]

You are both right. At a first sight, the flickering seemed to be gone, but even if it's much less noticeable (at least for me) it's still there.

[Chris Wilson (ickle)]

Found a hint with

commit b2245838c15b54d72557de8facb7cc15d59624ae
Author: Chris Wilson <email address hidden>
Date: Tue Nov 6 16:32:32 2012 +0000

    sna/gen4: opacity spans requires the per-rectangle flush w/a

    Note that this is worsened, but not caused, by:

    commit e1a63de8991a6586b83c06bcb3369208871cf43d
    Author: Chris Wilson <email address hidden>
    Date: Fri Nov 2 09:10:32 2012 +0000

        sna/gen4+: Prefer GPU spans if the destination is active

    References: https://bugs.freedesktop.org/show_bug.cgi?id=55500
    Signed-off-by: Chris Wilson <email address hidden>

Does this help?

[Mauro Fruet (maurofruet)]

I've just tested the latest git, but unfortunately the problem persists.

[Chris Wilson (ickle)]

Ok, looking closely on this gm45 I can see a similar subtle flicker in the chromium tabs. Is the effect still as severe as shown in the first video? Any improvements from the flushing changing?

[Mauro Fruet (maurofruet)]

Created attachment 69666
Screen capture for chromium tabs

I have attached a video screen capture that shows the flickering after installing the latest git version of xf86-video-intel, lib-drm and cairo. As I wrote in a previous comment, the problem is almost not noticeable. This is the same behavior that I have encountered just before the latest patch.

[Chris Wilson (ickle)]

I think the effect is now subtle enough that I'm not going to worry too much - it is undoubtably a missing flush or incorrect hw state. Since I can reproduce using the chromium tabs, I'll fix it one day (hopefully!). Please do ping occasionally to remind me, or if you have a found a particular nasty example.

[Joe Peterson (bx09m7e-say-zwnfzpm)]

(In reply to comment #30)
> I think the effect is now subtle enough that I'm not going to worry too much
> - it is undoubtably a missing flush or incorrect hw state. Since I can
> reproduce using the chromium tabs, I'll fix it one day (hopefully!). Please
> do ping occasionally to remind me, or if you have a found a particular nasty
> example.

Hey Chris, do you think this could be mainly a HW bug only on the older graphics chips? In other words, is the code obeying the spec, but it would take an odd (non-spec) workaround to make the HW behave?

If you have put in any extra flushes to try to fix this, perhaps those should now be removed so as not to affect performance adversely, especially if the extra ones affect newer HW as well (or did you only do it in the code for the old HW?).

I suspect I'll be upgrading from this old laptop soon for other reasons, so I agree that worrying too much about a hard-to-fix problem that only affects really old HW is probably not worth it (people could just turn off SNA on older HW, as long as UXA is supported for the foreseeable future).

[Chris Wilson (ickle)]

The code paths are specific for this chipset, and this flicker only seems to appear on gm45 for now. (Though I need to look at the other gen4 closely.)

And for the order of magnitude performance improvement switching from to UXA to SNA I think such a minor bug is a small price to pay... And it will be fixed as soon as I find a workaround.

[Jonathan Thomas (echidnaman)]

jonathan@jonathan-laptop:~/$ lspci -nn | grep VGA | sed 's/.*Intel Corporation //'
Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 09)
jonathan@jonathan-laptop:~/$

[Bryce Harrington (bryce)]

Confirmed, I was able to reproduce this on a Latitude 13 (cantiga gfx 8086:2a42) with stock Ubuntu/Unity. Full screenshot attached.

Mousing over the tab caused the corruption to move around from letter to letter. Was able to capture the corruption via a regular screen grab.

[Timo Jyrinki (timo-jyrinki)]

Not confirming on Zenbook, although just upgraded to the 3.8 and removed old kernels.

[Timo Aaltonen (tjaalton)]

Can't reproduce with Thinkpad X61 with i965GM, same generation as gm45. So please try with the latest kernel that is available since late yesterday.

[Timo Aaltonen (tjaalton)]

upstream pointed out the parent bug, seems like it's hard to reproduce so I might see it still.

[Zdenek Kabelac (zdenek-kabelac)]

Created attachment 92240
Text with errors

Recently I'm noticing somewhat more 'weird' behavior - it might be related to my temporal usage of night releases of Mozilla (since rawhide version got somewhat broken)

What is weird in this image is - the text was badly rendered AND it remained visible even when refreshed, even small scroll up/down left the text as is - it helped only to scroll text out of window and back.

So I assume now the rendering happens to some off-screen memory - which is then transfered back to screen with errors - and refresh doesn't help with this case.
(and it's a bit different then during typing text into input box).

Another probably unrelated comment could be - even when 'glxgears' is running in parallel - the visual errors still happens during typing of this text. I'd have expect the glxgears manages to 'overfill' GPU queue (since it's rendering ~1300FPS with default window) also the flushes are probably completely different. And - there is no observable rendering error in gears window - only Firefox seems to be exposing them.

[Edward Sheldrake (ejs1920)]

I am wondering if some extra flushes are needed in regard to what the G45 PRM PDFs say about the BLT (section 8.6, vol 1b p. 170)

git + this gives only a moderate amount of corrupt rendering:
diff --git a/src/sna/gen4_render.c b/src/sna/gen4_render.c
index e239c21..f150e5b 100644
--- a/src/sna/gen4_render.c
+++ b/src/sna/gen4_render.c
@@ -63,7 +63,7 @@
 #define NO_FILL_BOXES 0
 #define NO_VIDEO 0

-#define MAX_FLUSH_VERTICES 1 /* was 6, https://bugs.freedesktop.org/show_bug.cgi?id=55500 */
+#define MAX_FLUSH_VERTICES 12 /* was 6, https://bugs.freedesktop.org/show_bug.cgi?id=55500 */

 #define GEN4_GRF_BLOCKS(nreg) ((nreg + 15) / 16 - 1)

@@ -571,26 +571,28 @@ static void gen4_emit_vertex_buffer(struct sna *sna,
 inline static void
 gen4_emit_pipe_flush(struct sna *sna)
 {
-#if 1
+#if 0
  OUT_BATCH(GEN4_PIPE_CONTROL | (4 - 2));
- OUT_BATCH(GEN4_PIPE_CONTROL_WC_FLUSH);
+ OUT_BATCH(GEN4_PIPE_CONTROL_WC_FLUSH | GEN4_PIPE_CONTROL_TC_FLUSH);
  OUT_BATCH(0);
  OUT_BATCH(0);
 #else
  OUT_BATCH(MI_FLUSH | MI_INHIBIT_RENDER_CACHE_FLUSH);
+ /* OUT_BATCH(MI_NOOP); */
 #endif
 }

 inline static void
 gen4_emit_pipe_break(struct sna *sna)
 {
-#if 1
+#if 0
  OUT_BATCH(GEN4_PIPE_CONTROL | (4 - 2));
- OUT_BATCH(0);
+ OUT_BATCH(GEN4_PIPE_CONTROL_TC_FLUSH);
  OUT_BATCH(0);
  OUT_BATCH(0);
 #else
  OUT_BATCH(MI_FLUSH | MI_INHIBIT_RENDER_CACHE_FLUSH);
+ /* OUT_BATCH(MI_NOOP); */
 #endif
 }

@@ -599,11 +601,12 @@ gen4_emit_pipe_invalidate(struct sna *sna)
 {
 #if 0
  OUT_BATCH(GEN4_PIPE_CONTROL | (4 - 2));
- OUT_BATCH(GEN4_PIPE_CONTROL_WC_FLUSH | GEN4_PIPE_CONTROL_TC_FLUSH);
+ OUT_BATCH(GEN4_PIPE_CONTROL_WC_FLUSH | GEN4_PIPE_CONTROL_TC_FLUSH | GEN4_PIPE_CONTROL_IS_FLUSH);
  OUT_BATCH(0);
  OUT_BATCH(0);
 #else
- OUT_BATCH(MI_FLUSH);
+ OUT_BATCH(MI_FLUSH); /* | MI_STATE_INSTRUCTION_CACHE_FLUSH */
+ /* OUT_BATCH(MI_NOOP); */
 #endif
 }

@@ -781,7 +784,10 @@ gen4_emit_urb(struct sna *sna)
  urb_cl_end = urb_gs_end + URB_CL_ENTRIES * URB_CL_ENTRY_SIZE;
  urb_sf_end = urb_cl_end + URB_SF_ENTRIES * URB_SF_ENTRY_SIZE;
  urb_cs_end = urb_sf_end + URB_CS_ENTRIES * URB_CS_ENTRY_SIZE;
- assert(urb_cs_end <= 256);
+ if (sna->kgem.gen >= 045)
+ assert(urb_cs_end <= 384);
+ else
+ assert(urb_cs_end <= 256);

  while ((sna->kgem.nbatch & 15) > 12)
   OUT_BATCH(MI_NOOP);
@@ -1623,6 +1629,7 @@ gen4_render_composite_done(struct sna *sna,
   kgem_bo_destroy(&sna->kgem, op->src.bo);

  sna_render_composite_redirect_done(sna, op);
+ gen4_emit_pipe_invalidate(sna);
 }

 static bool
@@ -2154,6 +2161,7 @@ gen4_render_composite_spans_done(struct sna *sna,

  kgem_bo_destroy(&sna->kgem, op->base.src.bo);
  sna_render_composite_redirect_done(sna, &op->base);
+ gen4_emit_pipe_invalidate(sna);
 }

 static bool
@@ -2500,6 +2508,7 @@ fallback_blt:
  gen4_vertex_flush(sna);
  sna_render_composite_redirect_done(sna, &tmp);
  kgem_bo_destroy(&sna->kgem, tmp.src.bo);
+ gen4_emit_pipe_invalidate(sna);
  return true;

 fallback_tiled_dst:
@@ -2535,6 +2544,7 @@ gen4_render_copy_done(struct sna *sna, const struct sna_copy_op *op)
 {
  if (sna->render.vertex_offset)
   gen4_vertex_flush(sna);
+ gen4_emit_pipe_invalidate(sna);
 }

 static bool
@@ -2736,6 +2746,7 @@ gen4_render_fill_box...

[Zdenek Kabelac (zdenek-kabelac)]

I've not yet tested patch from comment 165 - but with regards to Firefox and Cairo - I'm also seeing errors in i.e. pidgin - where status icons looks occasionally damaged.

And my rawhide has these related packages:

cairo-1.13.1-0.1.git337ab1f.fc21.x86_64
cairo-gobject-1.13.1-0.1.git337ab1f.fc21.x86_64
pidgin-2.10.7-9.fc21.x86_64
xorg-x11-server-Xorg-1.15.0-1.fc21.x86_64
libX11-1.6.1-1.fc20.x86_64

 ldd /bin/pidgin
 linux-vdso.so.1 => (0x00007fff323ad000)
 libX11.so.6 => /lib64/libX11.so.6 (0x00007f6f151af000)
 libXext.so.6 => /lib64/libXext.so.6 (0x00007f6f14f9c000)
 libXss.so.1 => /lib64/libXss.so.1 (0x00007f6f14d98000)
 libSM.so.6 => /lib64/libSM.so.6 (0x00007f6f14b90000)
 libICE.so.6 => /lib64/libICE.so.6 (0x00007f6f14973000)
 libgtkspell.so.0 => /lib64/libgtkspell.so.0 (0x00007f6f1476c000)
 libgtk-x11-2.0.so.0 => /lib64/libgtk-x11-2.0.so.0 (0x00007f6f140e7000)
 libgdk-x11-2.0.so.0 => /lib64/libgdk-x11-2.0.so.0 (0x00007f6f13e25000)
 libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x00007f6f13c18000)
 libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f6f139f4000)
 libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f6f136ce000)
 libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x00007f6f134aa000)
 libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f6f1312b000)
 libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x00007f6f12f15000)
 libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f6f12cca000)
 libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f6f12a8e000)
 libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f6f127e9000)
 libpurple.so.0 => /lib64/libpurple.so.0 (0x00007f6f124af000)
 libdbus-glib-1.so.2 => /lib64/libdbus-glib-1.so.2 (0x00007f6f12287000)
 libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f6f1203e000)
 libfarstream-0.1.so.0 => /lib64/libfarstream-0.1.so.0 (0x00007f6f11e29000)
 libgstbase-0.10.so.0 => /lib64/libgstbase-0.10.so.0 (0x00007f6f11bd5000)
 libgstinterfaces-0.10.so.0 => /lib64/libgstinterfaces-0.10.so.0 (0x00007f6f119c2000)
 libgstreamer-0.10.so.0 => /lib64/libgstreamer-0.10.so.0 (0x00007f6f116d9000)
 libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f6f11487000)
 libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f6f11282000)
 libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f6f11080000)
 libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f6f10d54000)
 libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f6f109ea000)
 libidn.so.11 => /lib64/libidn.so.11 (0x00007f6f107b7000)
 libm.so.6 => /lib64/libm.so.6 (0x00007f6f104b1000)
 libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f6f10296000)
 libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f6f1007b000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6f0fe5d000)
 libc.so.6 => /lib64/libc.so.6 (0x00007f6f0fa95000)
 libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f6f0f874000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00007f6f0f670000)
 libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f6f0f46a000)
 libenchant.so.1 => /lib64/libenchant.so.1 (0x00007f6f0f25e000)
 libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f6f0f058000)
 libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f6f0ee4d000)
 libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f6f0ec4a000)
 libX...

[Harald Judt (hjudt)]

The image corruptions are also visible on the file/folder icons in thunar. I still have no glyph corruptions any more.

[Chris Wilson (ickle)]

Created attachment 92287
Always force a GPU flush between operations

Can you please try this patch against git and see if that improves things - except for performance?

[Zdenek Kabelac (zdenek-kabelac)]

ok - while doing a very quick & light check - at least on Firefox input window I do not observe any rendering bugs (which have been pretty simple to reach before).

(Lenovo T61 + git + patch from comment 168)

Thought the performance decrease is noticeable and also the setting for MAX_FLUSH... becomes irrelevant.

[Arkadiusz Miśkiewicz (arekm)]

Created attachment 92288
bug

f23ab963c4f4ada2051588dfc85264aa2798dbf7 + that patch and I'm seeing corruption. Using google-chrome and letters in url bar or window title bar sometimes get corrupted and then get fixed.

Also seeing the problem in gimp menus. Some letters get corrupted and fixed.

[Zdenek Kabelac (zdenek-kabelac)]

Ok - seem(In reply to comment #170)
> Created attachment 92288 [details]
> bug
>
> f23ab963c4f4ada2051588dfc85264aa2798dbf7 + that patch and I'm seeing
> corruption. Using google-chrome and letters in url bar or window title bar
> sometimes get corrupted and then get fixed.
>
> Also seeing the problem in gimp menus. Some letters get corrupted and fixed.

This could be related to my hw:

[219745.896] (II) intel(0): SNA compiled with assertions enabled
[219745.898] (--) intel(0): Integrated Graphics Chipset: Intel(R) 965GM
[219745.898] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3
[219745.898] (**) intel(0): Depth 24, (--) framebuffer bpp 32

And Arkadiusz hw:

[236338.852] (II) intel(0): SNA compiled with assertions enabled
[236338.853] (--) intel(0): Integrated Graphics Chipset: Intel(R) GM45
[236338.853] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1
[236338.853] (==) intel(0): Depth 24, (--) framebuffer bpp 32

On my 965GM I've not yet seen any error....

[penalvch (penalvch)]

Anirban Ghosh, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

[Edward Sheldrake (ejs1920)]

(In reply to comment #168)
> Created attachment 92287 [details] [review]
> Always force a GPU flush between operations
>
> Can you please try this patch against git and see if that improves things -
> except for performance?

Current git (2.99.907-23-gf23ab96) without any other changes: still a few corrupt characters in gedit with italic font

Current git + patch in attachment 92287: still the same - has a few corrupt characters in gedit with italic font, displaying files full of text

[Zdenek Kabelac (zdenek-kabelac)]

Update after some new commits:

4c7b183fd21b461f9f18662c3b9d9732b6bef13d + Always patch - now gives me broken text lines in Thunderbird window.

And it's now enough just to move the mouse over text and the text is changing and actually never renders correctly some letters.

Checking back f23ab963c4f4ada2051588dfc85264aa2798dbf7 + Always patch - again correct rendering.

This relates to GMA965.

[Chris Wilson (ickle)]

Created attachment 92512
Always force a GPU flush between operations

Updated always flush patch that passes Arkadiusz's stress test.

* sobs

[Edward Sheldrake (ejs1920)]

Created attachment 92770
not quite random corruption example

With the workarounds disabled, can anything be deduced from the text or pixmap corruption not seeming to be completely random?

Italic text seems to be particularly badly hit, and it seems to vary with the font and size. But in the attached screenshot, some of the lines of text never showed any corruption, while others usually showed some corruption, the corruption changing on switching focus to another window and back. Size 10 italic Cantarell seemed particularly badly hit, with even lines of just repeated c or d characters showing corruption (if longer than 18 letters), but other fonts don't usually show any corruption on a line of text filled with a single repeating character.

For pixmap corruption, the printer icon in the gedit toolbar seems to get turned into grey vertical bars more often than any other icons get corrupted.

[Chris Wilson (ickle)]

(In reply to comment #175)
> Created attachment 92770 [details]
> not quite random corruption example
>
> With the workarounds disabled, can anything be deduced from the text or
> pixmap corruption not seeming to be completely random?

It's not entirely random. What I have noticed is that one or more vertices are corrupt. Sometimes you see the correct content but skewed, which is what happens if you just move one of the vertices (its texture coordinates). With two or more distorted coordinates, we can be sampling from anywhere within the texture - which can mean that we see the wrong glyph or a highly distorted composite of several glyphs (since all the active glyphs are stored in a single texture).

[Edward Sheldrake (ejs1920)]

Running with all workarounds disabled, this change doesn't fix anything nor seem to make any difference, but anyway:
Shouldn't the cache flush bits be in dword 0 for gen4 GEN4_PIPE_CONTROL? Maybe gen5 also?

diff --git a/src/sna/gen4_render.c b/src/sna/gen4_render.c
index 1d164b6..894418b 100644
--- a/src/sna/gen4_render.c
+++ b/src/sna/gen4_render.c
@@ -575,8 +575,10 @@ inline static void
 gen4_emit_pipe_flush(struct sna *sna)
 {
 #if 1
- OUT_BATCH(GEN4_PIPE_CONTROL | (4 - 2));
- OUT_BATCH(GEN4_PIPE_CONTROL_WC_FLUSH);
+ OUT_BATCH(GEN4_PIPE_CONTROL |
+ GEN4_PIPE_CONTROL_WC_FLUSH |
+ (4 - 2));
+ OUT_BATCH(0);
  OUT_BATCH(0);
  OUT_BATCH(0);
 #else
@@ -601,8 +603,10 @@ inline static void
 gen4_emit_pipe_invalidate(struct sna *sna)
 {
 #if 0
- OUT_BATCH(GEN4_PIPE_CONTROL | (4 - 2));
- OUT_BATCH(GEN4_PIPE_CONTROL_WC_FLUSH | GEN4_PIPE_CONTROL_TC_FLUSH);
+ OUT_BATCH(GEN4_PIPE_CONTROL |
+ GEN4_PIPE_CONTROL_WC_FLUSH | GEN4_PIPE_CONTROL_TC_FLUSH |
+ (4 - 2));
+ OUT_BATCH(0);
  OUT_BATCH(0);
  OUT_BATCH(0);
 #else

[Edward Sheldrake (ejs1920)]

Created attachment 93235
sna/gen4,5: Fix setting pipe control cache flush bits

Only the one in gen4_emit_pipe_flush is in an enabled part of the code anyway.

[Lonnie Lee Best (launchpad-startport)]

I was expirening this bug in Ubuntu 13.10, but I've been running the 14.04 alpha for a few weeks now and haven't noticed it recently at all.

uname -a
Linux sidekick 3.13.0-6-generic #23-Ubuntu SMP Thu Jan 30 09:48:03 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I'll report back here if it comes back.

[Chris Wilson (ickle)]

Nevertheless it was a good catch.

commit 1cbc59a917e7352fc68aa0e26b1575cbd0ceab0d
Author: Edward Sheldrake <email address hidden>
Date: Mon Feb 3 09:34:33 2014 +0000

    sna/gen4,5: Fix setting pipe control cache flush bits

    Cache flush bits are on dword 0, not 1, on gen4 and gen5. Also texture
    cache invalidate is only available from Cantiga onwards.

[Edward Sheldrake (ejs1920)]

Created attachment 93326
icon corruption

Latest git (2.99.909-7-g1cbc59a) has icon corruption, but all text is fine.

[Chris Wilson (ickle)]

Sigh.

Probably,

diff --git a/src/sna/gen4_render.c b/src/sna/gen4_render.c
index 1580707..ba9c9bc 100644
--- a/src/sna/gen4_render.c
+++ b/src/sna/gen4_render.c
@@ -602,6 +602,7 @@ gen4_emit_pipe_break(struct sna *sna)
 inline static void
 gen4_emit_pipe_invalidate(struct sna *sna)
 {
+#if 0
        OUT_BATCH(GEN4_PIPE_CONTROL |
                  GEN4_PIPE_CONTROL_WC_FLUSH |
                  (sna->kgem.gen >= 045 ? GEN4_PIPE_CONTROL_TC_FLUSH : 0) |
@@ -609,6 +610,9 @@ gen4_emit_pipe_invalidate(struct sna *sna)
        OUT_BATCH(0);
        OUT_BATCH(0);
        OUT_BATCH(0);
+#else
+ OUT_BATCH(MI_FLUSH);
+#endif
 }

[Arkadiusz Miśkiewicz (arekm)]

(In reply to comment #181)

Without #181 patch I had flickering like:
http://ixion.pld-linux.org/~arekm/intel-flicker.mov
(best viewed from local fs)

With the patch flickering is gone.

"GM45" - synonym for all bad words :/

[Chris Wilson (ickle)]

Pushed the flushes once again. Hopefully we are corruption free once more.

commit fc001615ff78df4dab6ee0d5dd966b723326c358
Author: Chris Wilson <email address hidden>
Date: Tue Feb 4 10:36:21 2014 +0000

    sna/gen4: Disable use of pipecontrol invalidates again

    One day, just not today, we may make gen4 work correctly, efficiently and
    fast. Today, we can barely pick one.

    References: https://bugs.freedesktop.org/show_bug.cgi?id=55500
    Signed-off-by: Chris Wilson <<email address hidden>

[Chris Wilson (ickle)]

I'm keeping the upstream bug open to see if we can fix the performance implications of the workaround. But as far as the corruption is concerned, the fix has been release (and packaged by Ubuntu).

[Anirban Ghosh (anirban-ninja)]

I am having ATI video card. The problem still persists. Any idea on this?

[Jmadero (jmadero)]

I still have the same issue - not sure if it's made it into 13.10 repositories

[penalvch (penalvch)]

Jmadero, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report will delay your problem being addressed as quickly as possible.

Thank you for your understanding.

[Ildar (ildar-users)]

Created attachment 96026
GTK+2 fonts corruption

as per git, the commit is applied for the version 2.99.910. I have this version installed.
But the problem is still there, see the screenshot. Interestingly, the fonts are heavily corrupted in GTK+2 apps. QT/efl apps are fine. GTK+3 apps mainly ok, but gedit have icons corrupted a bit, but not fonts.

[Chris Wilson (ickle)]

(In reply to comment #184)
> Created attachment 96026 [details]
> GTK+2 fonts corruption
>
> as per git, the commit is applied for the version 2.99.910. I have this
> version installed.
> But the problem is still there, see the screenshot. Interestingly, the fonts
> are heavily corrupted in GTK+2 apps. QT/efl apps are fine. GTK+3 apps mainly
> ok, but gedit have icons corrupted a bit, but not fonts.

Please provide your Xorg.0.log to confirm this is the same bug.

[Ildar (ildar-users)]

Created attachment 96027
Xorg.log

[Chris Wilson (ickle)]

Ah, would you happen to have an uneven amount of memory installed?

[Ildar (ildar-users)]

(In reply to comment #187)
> Ah, would you happen to have an uneven amount of memory installed?

Probably. Is this and unsupported configuration?

[Harald Judt (hjudt)]

(In reply to comment #187)
> Ah, would you happen to have an uneven amount of memory installed?

I too have an uneven amount of memory installed (7 GiB). It's an old workhorse for office usage only, so dual-channel doesn't matter.

[Chris Wilson (ickle)]

(In reply to comment #188)
> (In reply to comment #187)
> > Ah, would you happen to have an uneven amount of memory installed?
>
> Probably. Is this and unsupported configuration?

We have a known issue in that we don't detect the swizzling correctly and so we may end up with corruption if objects are paged out from memory. Typically you see the affects after running for some time (so that memory pressure takes effect) or after resume. See bug 28813 bug 45092

[Ildar (ildar-users)]

true. Thanks a lot, Chris!

[Chris Wilson (ickle)]

*** Bug 76804 has been marked as a duplicate of this bug. ***

[Florian Hars (hars)]

I opened Bug #1314551 for the current AMD version of this behaviour and subscribed Christopher to it.

[David Pérez (david-perez-ingeniero)]

I'm experiencing also this nasty bug:

$ lspci|grep -i graphic
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)

After reading your technical comments, I don't know what to do in order to solve it.
I'm using KUbuntu 14.04.

[David Pérez (sanete)]

After reading this page https://downloadcenter.intel.com/product/81523/Graphics-Drivers-for-Intel-82Q963-Graphics-and-Memory-Controller-Hub-GMCH-, I see that latest official drivers from Intel date from august 2013.

Possible workarounds:

- Keep on using Linux and have to reboot every few hours to see text ok
- Install Windows, even though I prefer Linux.
- Buy another computer. (I don't like to do so, in an otherwise good working computer).
- Try to use another driver. Which one?

$ lsmod
Module Size Used by
i915 783805 2
video 19476 1 i915

I think the used driver is i915.

[David Pérez (sanete)]

I've found a relevant document about our bug:

There are a couple of backends available for accelerating the DDX. "UXA" (Unified Acceleration Architecture) is the mature backend that was introduced to support the GEM driver model. It is in the process of being superseded by "SNA" (Sandybridge's New Acceleration). Until that process is complete, the ability to choose which backend to use remains for backwards compatibility.

SNA is the default acceleration method in xf86-video-intel. If you are experience issues with SNA (e.g. pixelated graphics, corrupt text, etc.), try using UXA instead, which can be done by creating an X configuration file containing the following:
/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "AccelMethod" "uxa"
EndSection

Source: https://wiki.archlinux.org/index.php/Intel_graphics#SNA_issues

So, I've created a file called 60-patch-graphis.conf in the /usr/share/X11/xorg.conf.d folder, and reboot my system. I let you know about the results....

[penalvch (penalvch)]

David Pérez, as this report is closed, if you have a bug please file a new report via a terminal:
ubuntu-bug xorg

Please ensure you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

Also, please feel free to subscribe me to it.