From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 103408] [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes" Date: Sun, 22 Oct 2017 23:22:48 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1510062530==" 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 78E8689FF7 for ; Sun, 22 Oct 2017 23:22:48 +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 --===============1510062530== Content-Type: multipart/alternative; boundary="15087145680.FeCdA92.31151"; charset="UTF-8" --15087145680.FeCdA92.31151 Date: Sun, 22 Oct 2017 23:22:48 +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=3D103408 Bug ID: 103408 Summary: [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes" Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jb5sgc1n.nya@20mm.eu After updating my kernel compiled from https://cgit.freedesktop.org/~agd5f/linux/log/?h=3Damd-staging-drm-next rec= ently I noticed that when displaying videos full screen (displayed as 3840x2160 @ 23.9760 Hz) the replay would loose/drop frames every 10 to 20 seconds. I bisected the latest commits to amd-staging-drm-next and I could identify = one singe commit that 100% reproduceably introduces this symptom: 247258874c90af2b639b6f0dddd839c97464dacb is the first bad commit commit 247258874c90af2b639b6f0dddd839c97464dacb Author: Shirish S Date: Wed Sep 27 15:15:38 2017 +0530 drm/amd/display: add hardware_planes_only to list of affected planes For SoC's having software designed cursor plane, should be treated differently than hardware cursor planes. The DRM core initializes cursor plane by default with legacy_cursor_update set. Hence legacy_cursor_update can be use effectively to handle software cursor planes' update and atomicity functionalities. This patch uses this variable to decide in the atomic_check to whether add a requested plane to the list of affected planes or not, hence fixing the issue of co-existence of MPO, i.e, setting of available hardware planes like underlay and updation of cursor planes as well. Without this patch when underlay is set from user space, only blank screen with backlight is visible. Signed-off-by: Shirish S Reviewed-by: Harry Wentland When I revert just this commit from today's HEAD of amd-staging-drm-next, t= he frame drops are gone. How to reproduce: - Use an HDMI connected 3840x2160 display, with Option "TearFree" "On" in y= our Xorg config file amdgpu Device section. (Without "TearFree" "On", playing videos is totally uglyfied by teared frames, so it would be hard to notice = the dropped frames.) - Use "xrandr --output HDMI-A-0 --mode 3840x2160 --rate 23.976" to set your display to the refresh rate of the video - I only tried videos recorded at 23.976, don't know whether the same effect happens with other frame rates. - Use a player like "mpv" to full-screen(!) display a video that contains scenes with smooth panning - in such scenes, the effect of dropping frames = is most pronounced. You will also see the "dropped frame" count emitted in the status line of "mpv" increase. Possible other causes I ruled out: - Using different video-drivers with mpv - Xv, X11, opengl, all expose the = same symptom. - Using hardware (vaapi) versus software decoding makes no difference. - Using different parameters for mpv's "--video-sync=3D..." option makes no difference - the drops occur in every mode - Manually setting the GPU to e.g. cd /sys/class/drm/card0/device echo manual >power_dpm_force_performance_level echo 3 >pp_dpm_sclk echo 1 >pp_dpm_mclk=20 does not make a difference - the symptom occurs with and without this --=20 You are receiving this mail because: You are the assignee for the bug.= --15087145680.FeCdA92.31151 Date: Sun, 22 Oct 2017 23:22:48 +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 103408
Summary [bisected] frames dropped during video replay due to "ad= d hardware_planes_only to list of affected planes"
Product DRI
Version DRI git
Hardware x86-64 (AMD64)
OS Linux (All)
Status NEW
Severity normal
Priority medium
Component DRM/AMDgpu
Assignee dri-devel@lists.freedesktop.org
Reporter jb5sgc1n.nya@20mm.eu

After updating my kernel compiled from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=3Damd-staging-drm=
-next recently
I noticed that when displaying videos full screen (displayed as 3840x2160 &=
#64;
23.9760 Hz) the replay would loose/drop frames every 10 to 20 seconds.

I bisected the latest commits to amd-staging-drm-next and I could identify =
one
singe commit that 100% reproduceably introduces this symptom:

247258874c90af2b639b6f0dddd839c97464dacb is the first bad commit
commit 247258874c90af2b639b6f0dddd839c97464dacb
Author: Shirish S <shirish.s=
4;amd.com>
Date:   Wed Sep 27 15:15:38 2017 +0530

    drm/amd/display: add hardware_planes_only to list of affected planes

    For SoC's having software designed cursor plane,
    should be treated differently than hardware cursor planes.

    The DRM core initializes cursor plane by default with
    legacy_cursor_update set.

    Hence legacy_cursor_update can be use effectively
    to handle software cursor planes' update and atomicity
    functionalities.

    This patch uses this variable to decide in the atomic_check
    to whether add a requested plane to the list of affected planes or
    not, hence fixing the issue of co-existence of MPO, i.e,
    setting of available hardware planes like underlay and
    updation of cursor planes as well.

    Without this patch when underlay is set from user space,
    only blank screen with backlight is visible.

    Signed-off-by: Shirish S <s=
hirish.s@amd.com>
    Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>

When I revert just this commit from today's HEAD of amd-staging-drm-next, t=
he
frame drops are gone.

How to reproduce:

- Use an HDMI connected 3840x2160 display, with Option "TearFree"=
 "On" in your
Xorg config file amdgpu Device section. (Without "TearFree" "=
;On", playing
videos is totally uglyfied by teared frames, so it would be hard to notice =
the
dropped frames.)

- Use "xrandr --output HDMI-A-0 --mode 3840x2160 --rate 23.976" t=
o set your
display to the refresh rate of the video - I only tried videos recorded at
23.976, don't know whether the same effect happens with other frame rates.

- Use a player like "mpv" to full-screen(!) display a video that =
contains
scenes with smooth panning - in such scenes, the effect of dropping frames =
is
most pronounced. You will also see the "dropped frame" count emit=
ted in the
status line of "mpv" increase.

Possible other causes I ruled out:

- Using different video-drivers with mpv - Xv, X11, opengl, all expose the =
same
symptom.

- Using hardware (vaapi) versus software decoding makes no difference.

- Using different parameters for mpv's "--video-sync=3D..." optio=
n makes no
difference - the drops occur in every mode

- Manually setting the GPU to e.g.
   cd /sys/class/drm/card0/device
   echo manual >power_dpm_force_performance_level
   echo 3 >pp_dpm_sclk
   echo 1 >pp_dpm_mclk=20
  does not make a difference - the symptom occurs with and without this
        


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