From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 102683] mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs Date: Tue, 12 Sep 2017 16:52:04 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1276535929==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id B74CA6E6B9 for ; Tue, 12 Sep 2017 16:52:04 +0000 (UTC) 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 --===============1276535929== Content-Type: multipart/alternative; boundary="15052351240.8bAb2cEc.18481"; charset="UTF-8" --15052351240.8bAb2cEc.18481 Date: Tue, 12 Sep 2017 16:52:04 +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=3D102683 Bug ID: 102683 Summary: mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: bugs.freedesktop@haasn.xyz When rendering e.g. 24 Hz video on 60 Hz, `mpv`'s usage pattern consists of= one =E2=80=9Cfresh=E2=80=9D frame (e.g. 20ms rendering time) followed by two = =E2=80=9Credraw=E2=80=9D frames, each of which are essentially just blits/mixes of already-rendered frames. This results in a high-low-low-high-low GPU activity pattern. Apparently this confuses the GPU frequency scaling quite heavily, which lea= ds to bad performance (under-scaling), inconsistent performance (=E2=80=9Cflap= ping=E2=80=9D SCLK) and missed vblanks (delayed/dropped frames and vsync jitter as measured by mpv). If I `watch -n0.1 cat /sys/kernel/debug/dri/*/amdgpu_pm_info`, I can = see it varying wildly between `SCLK: 500 MHz` and `SCLK: 1000 MHz`, as the repo= rted `GPU Load:` varies between 0% and 100% from frame to frame. I can consisten= tly solve the issue by setting `power_dpm_force_performance_level` to `high`. A graphical explanation of the issue, with mpv performance graphs: `auto`: https://0x0.st/7qz.jpg `high`: https://0x0.st/7qi.jpg This is not just cosmetic, since it results in an increase in the number of missed vsyncs, due to the occasional spikes. I've also had a different user report significantly worse performance with 'auto', even more extreme than = my example: https://0x0.st/7Aw.jpg (Note: the third step in this image, going = from 10k ms to 5k ms is due to switching from mesa 17.2 to 17.1; but that's an unrelated, cosmetic bug). Using 'auto' makes mpv completely unusable for th= is user. I expect the solution would be adding a tiny bit of (top-weighted) smoothin= g of this performance state / GPU load estimation across frames. The nvidia driv= er, for example, gets this right: If I alter between 'high' performance and 'lo= w' performance states, it recognizes that and sticks to 'high' performance mod= e, instead of varying the frequency wildly like amdgpu. This results in very f= lat graphs, much like the 'high' screenshot I uploaded. Kernel version is 4.12.4, mesa version is 17.2.0, device is a Sapphire RX 5= 60. --=20 You are receiving this mail because: You are the assignee for the bug.= --15052351240.8bAb2cEc.18481 Date: Tue, 12 Sep 2017 16:52:04 +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
Bug ID 102683
Summary mpv confuses the frequency scaling, leading to freqyency flap= ping and missed vsyncs
Product DRI
Version unspecified
Hardware x86-64 (AMD64)
OS Linux (All)
Status NEW
Severity normal
Priority medium
Component DRM/AMDgpu
Assignee dri-devel@lists.freedesktop.org
Reporter bugs.freedesktop@haasn.xyz

When rendering e.g. 24 Hz video on 60 Hz, `mpv`'s usage patter=
n consists of one
=E2=80=9Cfresh=E2=80=9D frame (e.g. 20ms rendering time) followed by two =
=E2=80=9Credraw=E2=80=9D frames, each
of which are essentially just blits/mixes of already-rendered frames. This
results in a high-low-low-high-low GPU activity pattern.

Apparently this confuses the GPU frequency scaling quite heavily, which lea=
ds
to bad performance (under-scaling), inconsistent performance (=E2=80=9Cflap=
ping=E2=80=9D SCLK)
and missed vblanks (delayed/dropped frames and vsync jitter as measured by
mpv). If I `watch -n0.1 cat /sys/kernel/debug/dri/*/amdgpu_pm_info`, I can =
see
it varying wildly between `SCLK: 500 MHz` and `SCLK: 1000 MHz`, as the repo=
rted
`GPU Load:` varies between 0% and 100% from frame to frame. I can consisten=
tly
solve the issue by setting `power_dpm_force_performance_level` to `high`.

A graphical explanation of the issue, with mpv performance graphs:
`auto`: https://0x0.st/7qz.jpg
`high`: https://0x0.st/7qi.jpg

This is not just cosmetic, since it results in an increase in the number of
missed vsyncs, due to the occasional spikes. I've also had a different user
report significantly worse performance with 'auto', even more extreme than =
my
example: https://0x0.st/7Aw.jpg (Not=
e: the third step in this image, going from
10k ms to 5k ms is due to switching from mesa 17.2 to 17.1; but that's an
unrelated, cosmetic bug). Using 'auto' makes mpv completely unusable for th=
is
user.

I expect the solution would be adding a tiny bit of (top-weighted) smoothin=
g of
this performance state / GPU load estimation across frames. The nvidia driv=
er,
for example, gets this right: If I alter between 'high' performance and 'lo=
w'
performance states, it recognizes that and sticks to 'high' performance mod=
e,
instead of varying the frequency wildly like amdgpu. This results in very f=
lat
graphs, much like the 'high' screenshot I uploaded.

Kernel version is 4.12.4, mesa version is 17.2.0, device is a Sapphire RX 5=
60.


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