Bug 98746 - [BSW] Artifacts left on screen when using DRI3
Summary: [BSW] Artifacts left on screen when using DRI3
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2016-11-16 13:55 UTC by Pekka Jylhä-Ollila
Modified: 2019-11-27 13:46 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Desktop artifacts (103.70 KB, image/png)
2016-11-16 13:55 UTC, Pekka Jylhä-Ollila
no flags Details
dmesg (40.86 KB, text/plain)
2016-11-16 13:56 UTC, Pekka Jylhä-Ollila
no flags Details
DRI2 Xorg.0.log (14.77 KB, text/plain)
2016-11-16 13:57 UTC, Pekka Jylhä-Ollila
no flags Details
DRI3 Xorg.0.log (14.72 KB, text/plain)
2016-11-16 13:58 UTC, Pekka Jylhä-Ollila
no flags Details

Description Pekka Jylhä-Ollila 2016-11-16 13:55:50 UTC
Created attachment 128007 [details]
Desktop artifacts

Using the latest drm-intel-nightly kernel, XServer and DDX driver on Ubuntu 16.04 with DRI3 leaves artifacts on the screen on BSW.

The screen shows previous content when it's refreshed while using the desktop (see screenshot). This doesn't happen with DRI2, only with DRI3. 3D rendering works correctly.
Comment 1 Pekka Jylhä-Ollila 2016-11-16 13:56:22 UTC
Created attachment 128008 [details]
Comment 2 Pekka Jylhä-Ollila 2016-11-16 13:57:26 UTC
Created attachment 128009 [details]
DRI2 Xorg.0.log
Comment 3 Pekka Jylhä-Ollila 2016-11-16 13:58:06 UTC
Created attachment 128010 [details]
DRI3 Xorg.0.log
Comment 4 Chris Wilson 2016-11-16 14:19:03 UTC
A software cursor.
Comment 5 Pekka Jylhä-Ollila 2016-11-16 15:24:03 UTC
(In reply to Chris Wilson from comment #4)
> A software cursor.

Trying to set 'Option "SWCursor" "on"' or 'Option "HWCursor" "off"' in an Xorg configuration file resulted in 'Option "SWCursor" is not used'.
Am I configuring Xorg wrong, or is this not supported?
Comment 6 Chris Wilson 2016-11-16 15:31:39 UTC
That config is not used. A software cursor is employed as a fallback when the hw cursor fails. It shouldn't cause a visible trail, that would be DRI3 not sync'ing correctly (known), but we shouldn't be hitting the swcursor either (except for when the cursor goes slightly out of bounds on pipe C on bsw). I'm more worried about why we have a swcursor here.
Comment 7 Martin Peres 2019-11-27 13:46:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/129.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.