All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 102683] mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs
@ 2017-09-12 16:52 bugzilla-daemon
  2017-09-18  1:13 ` bugzilla-daemon
  0 siblings, 1 reply; 2+ messages in thread
From: bugzilla-daemon @ 2017-09-12 16:52 UTC (permalink / raw)
  To: dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 2637 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=102683

            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
“fresh” frame (e.g. 20ms rendering time) followed by two “redraw” 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 leads
to bad performance (under-scaling), inconsistent performance (“flapping” 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 reported
`GPU Load:` varies between 0% and 100% from frame to frame. I can consistently
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 this
user.

I expect the solution would be adding a tiny bit of (top-weighted) smoothing of
this performance state / GPU load estimation across frames. The nvidia driver,
for example, gets this right: If I alter between 'high' performance and 'low'
performance states, it recognizes that and sticks to 'high' performance mode,
instead of varying the frequency wildly like amdgpu. This results in very flat
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 560.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4058 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug 102683] mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs
  2017-09-12 16:52 [Bug 102683] mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs bugzilla-daemon
@ 2017-09-18  1:13 ` bugzilla-daemon
  0 siblings, 0 replies; 2+ messages in thread
From: bugzilla-daemon @ 2017-09-18  1:13 UTC (permalink / raw)
  To: dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 1065 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=102683

Niklas Haas <bugs.freedesktop@haasn.xyz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Niklas Haas <bugs.freedesktop@haasn.xyz> ---
Re-testing this I noticed that it's possible */amdgpu_pm_info just delivers
more unrealiable data or something; with GALLIUM_HUD_PERIOD=0
GALLIUM_HUD=shader-clock,gpu-load I noticed it working much better.

As for the “performance issues”, I think it may be because of timers getting
confused due to the change in frequency? Re-testing I can't notice more dropped
frames than usual except at the very beginning, probably due to the very fact
that it does frequency scaling.

I'll close this issue unless I have something more concrete to report.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2685 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-09-18  1:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-12 16:52 [Bug 102683] mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs bugzilla-daemon
2017-09-18  1:13 ` bugzilla-daemon

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.