<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [SKL] [bisected] [regression] Artifacts when running window manager remotely"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104528">104528</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[SKL] [bisected] [regression] Artifacts when running window manager remotely
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>XOrg git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>manio@skyboo.net
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Hello.
I am running enlightenment WM from a lxc container on one of my screen. To run
it I am logging via ssh and I am passing export DISPLAY=:0 then
'enlightenment_start'. All was working flawlessly until I upgraded my stock
debian kernel today. I switched from stable kernel 4.11 to 4.12+ (also tested
on 4.13, 4.14 and also on 4.15.0-rc5).
The problem exist on all kernels above 4.11.
After running 'enlightenment_start' the screen is starting to flicker and I
cannot normally work. I can see that it flickers mostly when some screen
regions are redrawn by enlightenment (it has a clock with seconds displayed).
And because a picture is worth a thousand words, so I recorded a short movie
with this artifact effect:
<a href="http://skyboo.net/temp/drm-bug/VID_20180107_053715.mp4">http://skyboo.net/temp/drm-bug/VID_20180107_053715.mp4</a>
I spent several hours compiling the kernels to track down the problem, and
finally I've bisected the single commit from which the problem started to
happen:
616d9cee4fdc4a377c03be8fd6efa5df4fcd0d81 is the first bad commit
commit 616d9cee4fdc4a377c03be8fd6efa5df4fcd0d81
Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Date: Fri Jun 16 15:05:21 2017 +0100
drm/i915: First try the previous execbuffer location
When choosing a slot for an execbuffer, we ideally want to use the same
address as last time (so that we don't have to rebind it) and the same
address as expected by the user (so that we don't have to fixup any
relocations pointing to it). If we first try to bind the incoming
execbuffer->offset from the user, or the currently bound offset that
should hopefully achieve the goal of avoiding the rebind cost and the
relocation penalty. However, if the object is not currently bound there
we don't want to arbitrarily unbind an object in our chosen position and
so choose to rebind/relocate the incoming object instead. After we
report the new position back to the user, on the next pass the
relocations should have settled down.
Signed-off-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Reviewed-by: Joonas Lahtinen <<a href="mailto:joonas.lahtien@linux.intel.com">joonas.lahtien@linux.intel.com</a>>
:040000 040000 2cf47689666547b40b9aacee05ee208713f1616b
b857932a3e91700e68a9b236e6a5ea475cfa54f6 M drivers
Distro: debian buster/sid
Screen configuration: separate xorg instance only for integrated intel graphics
(two displays: HDMI for kodi, DP for enlightenment)
CPU: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>