From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows Date: Mon, 19 Nov 2018 22:48:37 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0930957558==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 403846E2CF for ; Mon, 19 Nov 2018 22:48:37 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0930957558== Content-Type: multipart/alternative; boundary="15426677173.cFa9db4.9616" Content-Transfer-Encoding: 7bit --15426677173.cFa9db4.9616 Date: Mon, 19 Nov 2018 22:48:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D106175 --- Comment #52 from Brandon Wright --- Ok, I think I understand what's going on. Forgive me if this sounds stupid,= I'm looking at the DRM code for the first time. The old KMS interface uses what's flagged as "legacy" cursor updates. These= are "asynchronous" in that they're handled and passed to the hardware as they c= ome in. On the vertical retrace interrupt, it uses whatever the last data passe= d in was.=20 My theory is the DC interface isn't passing these on to the hardware immediately. It's aggregating them until the next sync, when they're all handled at once. And that is what's causing the disturbance at page-flip ti= me. High-report-rate mice might exacerbate it. Intel's driver hasn't merged that async code yet. It's still using legacy cursor updates and working around this. The DC code seems to have a TODO comment in amdgpu_dm.c that suggests somet= hing about the legacy_cursor_update flag, but it doesn't do anything with it. --=20 You are receiving this mail because: You are the assignee for the bug.= --15426677173.cFa9db4.9616 Date: Mon, 19 Nov 2018 22:48:37 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comme= nt # 52 on bug 10617= 5 from Brandon Wright 
Ok, I think I understand what's going on. Forgive me if this s=
ounds stupid, I'm
looking at the DRM code for the first time.

The old KMS interface uses what's flagged as "legacy" cursor upda=
tes. These are
"asynchronous" in that they're handled and passed to the hardware=
 as they come
in. On the vertical retrace interrupt, it uses whatever the last data passe=
d in
was.=20

My theory is the DC interface isn't passing these on to the hardware
immediately. It's aggregating them until the next sync, when they're all
handled at once. And that is what's causing the disturbance at page-flip ti=
me.
High-report-rate mice might exacerbate it.

Intel's driver hasn't merged that async code yet. It's still using legacy
cursor updates and working around this.

The DC code seems to have a TODO comment in amdgpu_dm.c that suggests somet=
hing
about the legacy_cursor_update flag, but it doesn't do anything with it.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15426677173.cFa9db4.9616-- --===============0930957558== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0930957558==--