Device logs and video: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/781060/

Also seen on switching between VT1 and VT2

Moving the mouse fixes the issue; I'm moving this to a beta-blocker rather than dev.  P

Acceptable, Albert?

"Acceptable" = needs to be investigated but we're proceeding with the dev push.  Sorry it wasn't clearer.

Repro'd issue only on link. No repro on caroline, samus, quawks

I also see this on:

Google Chrome	64.0.3255.0 (Official Build) dev (64-bit)
Revision	0
Platform	10089.0.0 (Official Build) dev-channel panther
Firmware Version	Google_Panther.4920.24.26
Customization ID	PANTHER
JavaScript	V8 6.4.177
Flash	27.0.0.183 

 Issue 781884  has been merged into this issue.

Panther, Link? They are all on kernel 3.8. I wonder if there is something missing in 3.8 that Mesa needs now?

Bisect shrinks the mesa commit range to 3f353342a6 - 6c530ad116
No UI flickering is detected before mesa commit 3f353342a6, which enables I915_EXEC_NO_RELOC as many places as possible. 

The full list of suspicious commits are
6c530ad116	i965: Reduce passing 2x32b of reloc_domains to 2 bits
2aacd22c0b	i965: Convert reloc.target_handle into an index for I915_EXEC_HANDLE_LUT
4d26c77a71	i965: Use a C99 initializer for new validation list entries.
68d611ed8e	i965: Simplify some bo != batch->bo special cases.
29ba502a4e	i965: Use I915_EXEC_BATCH_FIRST when available.
e24f3fb7c8	i965: Move add_exec_bo()
ba9b71e56a	i965: Ignore reloc read/write domains
3f353342a6	i965: Use I915_EXEC_NO_RELOC

add a screenshot as a reference.

Deleted: graphics_VTSwitch_VT1-1.bmp 12.5 MB

graphics_VTSwitch_VT1-1.bmp 12.5 MB Download

Hi, this is tagged as a beta blocker for M64.  We're not that far out and this bug hasn't been updated in a while.  Ping?  Thanks...

I'm also seeing severe screen issues and crashes on my Acer Chromebox i3 (panther) for the last 5 Dev builds (MS 64), but not just on the login screen.

There's flickering and artifacts during normal use up to complete system crashes, too.

It seems to be triggered by using a 4K screen via HDMI, as the Samsung U28D590 I have connected.

I can avoid those crashes by switching DisplayPort, capping the resolution at 2560 x 1440, or attaching a Full HD (1920 x 1080) screen via HDMI instead.

Reverting to the Beta channel (MS 63) completely eliminates all the issues.

having a fix CL:810212 right now. It is caused by kernel 3.8 does not support I915_EXEC_NO_RELOC label, which is introduced in mesa uprev in 10077.0.0. 

Thanks; let's be sure to merge if needed to unblock the M64 beta block status.  We're targeting next Tuesday 12-Dec for Beta, so whatever needs to move it along.  Thanks!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9cc3363a3c20e7e7610183cb23312a5fc3b6cfd1

commit 9cc3363a3c20e7e7610183cb23312a5fc3b6cfd1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Dec 08 08:37:01 2017

UPSTREAM: drm/i915: Allow userspace to hint that the relocations were known

Userspace is able to hint to the kernel that its command stream and
auxiliary state buffers already hold the correct presumed addresses and
so the relocation process may be skipped if the kernel does not need to
move any buffers in preparation for the execbuffer. Thus for the common
case where the allotment of buffers is static between batches, we can
avoid the overhead of individually checking the relocation entries.

Note that this requires userspace to supply the domain tracking and
requests for workarounds itself that would otherwise be computed based
upon the relocation entries.

Using copywinwin10 as an example that is dependent upon emitting a lot
of relocations (2 per operation), we see improvements of:

c2d/gm45: 618000.0/sec to 632000.0/sec.
i3-330m: 748000.0/sec to 830000.0/sec.

(measured relative to a baseline with neither optimisations applied).

BUG= chromium:781060 
TEST=test_that link graphics_VTSwitch --iteration 10
     and manually check if the screen is corrupted.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Fixup merge conflict in userspace header due to different
baseline trees.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit ed5982e6ce5f106abcbf071f80730db344a6da42)
Signed-off-by: Po-Hsien Wang <pwang@chromium.org>

Change-Id: Ic4603b81a53c2f631e8e3fcb828f7f59e6ee2f0a
Reviewed-on: https://chromium-review.googlesource.com/810212
Commit-Ready: Po-Hsien Wang <pwang@chromium.org>
Tested-by: Po-Hsien Wang <pwang@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

[modify] https://crrev.com/9cc3363a3c20e7e7610183cb23312a5fc3b6cfd1/drivers/gpu/drm/i915/i915_dma.c
[modify] https://crrev.com/9cc3363a3c20e7e7610183cb23312a5fc3b6cfd1/include/uapi/drm/i915_drm.h
[modify] https://crrev.com/9cc3363a3c20e7e7610183cb23312a5fc3b6cfd1/drivers/gpu/drm/i915/i915_gem_execbuffer.c

Hey, I never got the merge request so never made the approval.  Were steps taken to merge into the M64 branch?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/676824da5419ddaa6b5f34d9914f7e068512a302

commit 676824da5419ddaa6b5f34d9914f7e068512a302
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jan 05 06:14:16 2018

UPSTREAM: drm/i915: Allow userspace to hint that the relocations were known

Userspace is able to hint to the kernel that its command stream and
auxiliary state buffers already hold the correct presumed addresses and
so the relocation process may be skipped if the kernel does not need to
move any buffers in preparation for the execbuffer. Thus for the common
case where the allotment of buffers is static between batches, we can
avoid the overhead of individually checking the relocation entries.

Note that this requires userspace to supply the domain tracking and
requests for workarounds itself that would otherwise be computed based
upon the relocation entries.

Using copywinwin10 as an example that is dependent upon emitting a lot
of relocations (2 per operation), we see improvements of:

c2d/gm45: 618000.0/sec to 632000.0/sec.
i3-330m: 748000.0/sec to 830000.0/sec.

(measured relative to a baseline with neither optimisations applied).

BUG= chromium:781060 
TEST=test_that link graphics_VTSwitch --iteration 10
     and manually check if the screen is corrupted.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Fixup merge conflict in userspace header due to different
baseline trees.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit ed5982e6ce5f106abcbf071f80730db344a6da42)
Signed-off-by: Po-Hsien Wang <pwang@chromium.org>

Change-Id: Ic4603b81a53c2f631e8e3fcb828f7f59e6ee2f0a
Reviewed-on: https://chromium-review.googlesource.com/810212
Commit-Ready: Po-Hsien Wang <pwang@chromium.org>
Tested-by: Po-Hsien Wang <pwang@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
(cherry picked from commit 9cc3363a3c20e7e7610183cb23312a5fc3b6cfd1)
Reviewed-on: https://chromium-review.googlesource.com/848552
Reviewed-by: Po-Hsien Wang <pwang@chromium.org>

[modify] https://crrev.com/676824da5419ddaa6b5f34d9914f7e068512a302/drivers/gpu/drm/i915/i915_dma.c
[modify] https://crrev.com/676824da5419ddaa6b5f34d9914f7e068512a302/include/uapi/drm/i915_drm.h
[modify] https://crrev.com/676824da5419ddaa6b5f34d9914f7e068512a302/drivers/gpu/drm/i915/i915_gem_execbuffer.c

 Issue 798885  has been merged into this issue.

810212 merge landed at 10176.40.0