Bug 93125 - Rendering artifacts in SNA for small regions
Summary: Rendering artifacts in SNA for small regions
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-26 14:58 UTC by Jaroslav Škarvada
Modified: 2016-05-24 08:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Škarvada 2015-11-26 14:58:25 UTC
On Fedora 22 with SNA I encountered the following rendering artifacts when used emerald decorator:
https://bugzilla.redhat.com/attachment.cgi?id=1096086

HW used:
graphics:  Card: Intel Haswell-ULT Integrated Graphics Controller
           Display Server: Fedora X.org 117.4 drivers: intel (unloaded: fbdev,vesa)
           Resolution: 1366x768@60.00hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile
           GLX Version: 3.0 Mesa 10.6.9 (git-8957b69)

It seems the problem was caused by the following commit:
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=ef24cb1b223486d7dfe57f33c28d8692f9857c98

It works correctly in UXA. It works in SNA if I use git snapshot before the above mentioned commit or even with the latest git head with the reverted above mentioned commit.

It also works correctly with different drivers (e.g. nvidia).

I think it should work the same in UXA/SNA, thus filling this bug.

Downstream Fedora bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1283225
Comment 1 Chris Wilson 2015-11-26 16:00:50 UTC
That's quite peculiar. The blitter should be quite capable and is well used...

diff --git a/src/sna/gen7_render.c b/src/sna/gen7_render.c
index 1c420a7..e896816 100644
--- a/src/sna/gen7_render.c
+++ b/src/sna/gen7_render.c
@@ -54,7 +54,7 @@
 #define NO_COMPOSITE 0
 #define NO_COMPOSITE_SPANS 0
 #define NO_COPY 0
-#define NO_COPY_BOXES 0
+#define NO_COPY_BOXES 1
 #define NO_FILL 0
 #define NO_FILL_BOXES 0
 #define NO_FILL_ONE 0

Will force all of these paths through the blitter. Would also be good to check with Option "AccelMethod" "blt". If you could undo the small_copy() one by one to identify the path that fails, that would also be useful. Once you have that,
adding

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 3341851..1dccc65 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -1087,8 +1087,12 @@ sna_pixmap_create_scratch(ScreenPtr screen,
 
 static unsigned small_copy(const RegionRec *region)
 {
-       if ((region->extents.x2 - region->extents.x1)*(region->extents.y2 - regi
+       if ((region->extents.x2 - region->extents.x1)*(region->extents.y2 - regi
+               DBG(("%s: region:%dx%d\n", __FUNCTION__,
+                    (region->extents.x2 - region->extents.x1),
+                    (region->extents.y2 - region->extents.y1));
                return COPY_SMALL;
+               }
 
        return 0;
 }

and recompiling with ./configure --enable-debug=full will generate a huge log file that I would hopefully be able to find the bug.
Comment 2 Jaroslav Škarvada 2015-12-01 14:06:55 UTC
Sorry for delay, I haven't access to the affected machine. I will try to provide the requested debug information during today.

Also this doesn't seem to be reproducible on all intel adapters.
Comment 3 Jaroslav Škarvada 2015-12-03 17:39:41 UTC
I played with this for few days and it's weird. With debugging enabled the UI is drawn apparently slower, but there are no artifacts. The artifacts starts appearing with debugging disabled. Maybe some race is encountered with the faster draw, I don't know. If this is user space problem, I can't understand why it is not reproducible with different drivers/graphics cards. I will try to prepare stripped down reproducer and let's see.
Comment 4 Jaroslav Škarvada 2016-04-27 16:55:26 UTC
Emerald upstream acknowledged the problem and as an workaround moved from the  Xlib surfaces to Cairo image surfaces in this commit:
https://github.com/compiz-reloaded/emerald/commit/c223562

But Xlib surfaces shouldn't behave differently in comparison to the Cairo image surfaces.

This problem seems reproducible only with some Intel adapters in SNA mode.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.