Bug 103408

Summary: [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes"
Product: DRI Reporter: dwagner <jb5sgc1n.nya>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: harry.wentland, jordan.lazare
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
1-minute test video, smooth horizontal pan in 3840x2160 23.976 fps
none
check if modeset is required before adding plane none

Description dwagner 2017-10-22 23:22:48 UTC
After updating my kernel compiled from https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next recently 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 <shirish.s@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 <shirish.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, the 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" 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=..." 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 
  does not make a difference - the symptom occurs with and without this
Comment 1 dwagner 2017-10-23 23:18:02 UTC
Created attachment 135018 [details]
1-minute test video, smooth horizontal pan in 3840x2160 23.976 fps

For more convenient reproducability, I created and attached a one-minute sample video file, which just contains a smooth horizontal pan over big letters.

When I replay this file with the defect, about 7 frames are dropped, easily spottable as harsh temporary stops in the normally smooth scrolling.
Comment 2 Andy Furniss 2017-10-25 18:56:28 UTC
I can reproduce this on R9 285 with a different setup.

Made a 60fps 1920x1080 from the vid here, lengthened by repeating 4x + added time counter, removed audio.

Monitor is 60Hz 1920x1080 DVI-D. CPU and GPU on perf. No TearFree, but same results if on (I don't need tearfree due to not using a compositing desktop).

mpv vo=vdpau/opengl/vaapi = mostly 10 sec glitches some 20.

kodi = every 5 seconds.

mplayer = 30 seconds.

With the commit reverted all are glitch free.

Also notice that wayland/weston (composited full screen) doesn't have the issue.
Comment 3 shirish.s 2017-10-26 14:00:58 UTC
Created attachment 135062 [details] [review]
check if modeset is required before adding plane
Comment 4 shirish.s 2017-10-26 14:04:26 UTC
I have tested the bisected patch:

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

in ChromeOS on Stoney platform and did not find any regression during rendering or video p/b, also may be the reason why Andy Furniss did not see the issue on composited full screen.

I have attached a patch in anticipation to the description of bug, please try it and let me know if it works.
Comment 5 Andy Furniss 2017-10-26 20:51:07 UTC
Patch is good for me, thanks.
Comment 6 dwagner 2017-10-26 21:45:16 UTC
Yes, the patch fixes this issue for me, too. Thank!
Comment 7 shirish.s 2017-10-27 03:28:25 UTC
Cool, will get the patch reviewed and merged.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.