[Bug 104528] New: [SKL] [bisected] [regression] Artifacts when running window manager remotely

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=104528

            Bug ID: 104528
           Summary: [SKL] [bisected] [regression] Artifacts when running
                    window manager remotely
           Product: DRI
           Version: XOrg git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: manio at skyboo.net
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

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:
http://skyboo.net/temp/drm-bug/VID_20180107_053715.mp4

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 <chris at chris-wilson.co.uk>
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 <chris at chris-wilson.co.uk>
    Reviewed-by: Joonas Lahtinen <joonas.lahtien at linux.intel.com>

: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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180107/3c720b04/attachment.html>