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==--