Bug 103486

Summary: Tonga DC vblank_mode=0 not working as expected fullscreen
Product: DRI Reporter: Andy Furniss <adf.lists>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: bhawanpreet.lakha, harry.wentland
Version: DRI git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Patch to fix vblank_mode not working properly
none
Unix-style line terminators none

Description Andy Furniss 2017-10-27 15:50:41 UTC
R9285, I notice that on both drm-next-4.15-dc and amd-staging-drm-next, when using DC, vblank_mode=0 works windowed but not properly full screen.

Tried forcing TearFree from auto to off no difference.

There is no tearing where it would be expected - but it's not like it's just being ignored, a bench mark test will cap fps at 2X refresh rate rather than 1X.

Maybe this is expected?

It doesn't happen with a months older DC kernel I have and looking at DC benches on Phoronix I don't see any fps cap.
Comment 1 Michel Dänzer 2017-10-27 16:14:45 UTC
(In reply to Andy Furniss from comment #0)
> R9285, I notice that on both drm-next-4.15-dc and amd-staging-drm-next,

Which commit exactly of amd-staging-drm-next?


> when using DC, vblank_mode=0 works windowed but not properly full screen.
> 
> Tried forcing TearFree from auto to off no difference.

That's expected; forcing TearFree on works around the problem though. :)


> There is no tearing where it would be expected - but it's not like it's just
> being ignored, a bench mark test will cap fps at 2X refresh rate rather than
> 1X.
> 
> Maybe this is expected?

Definitely not, looks like there's been a regression affecting async flips.


> It doesn't happen with a months older DC kernel I have [...]

Can you try bisecting? Otherwise I'll try next week.
Comment 2 Andy Furniss 2017-10-27 20:17:19 UTC
(In reply to Michel Dänzer from comment #1)
> (In reply to Andy Furniss from comment #0)
> > R9285, I notice that on both drm-next-4.15-dc and amd-staging-drm-next,
> 
> Which commit exactly of amd-staging-drm-next?

I was the version before 11h ago update at time of filing bug,

4ce527eb8bb3c4130f3f6bcd9b4b2efe25fcd534
drm/amdgpu: Remove job->s_entity to avoid keeping reference to stale pointer

I first noticed on the version before that, while testing a different bug but don't have the head commit available. I've just updated to what is current now and it's the same. I see loads of warnings at startup, but see these have already been reported.

7781a8c68a6ad110e0d3e11a38357b599ab04da3
drm/amdgpu: remove extra parameter from amdgpu_ttm_bind() v2

> > when using DC, vblank_mode=0 works windowed but not properly full screen.
> > 
> > Tried forcing TearFree from auto to off no difference.
> 
> That's expected; forcing TearFree on works around the problem though. :)

Ahh, so it does. I knew auto should = off for me, but it was worth being explicit.

> > There is no tearing where it would be expected - but it's not like it's just
> > being ignored, a bench mark test will cap fps at 2X refresh rate rather than
> > 1X.
> > 
> > Maybe this is expected?
> 
> Definitely not, looks like there's been a regression affecting async flips.
> 
> 
> > It doesn't happen with a months older DC kernel I have [...]
> 
> Can you try bisecting? Otherwise I'll try next week.

I'll try, I just didn't want to start if this was already known/expected.
Comment 3 Andy Furniss 2017-10-27 23:03:58 UTC
786fb38531e8be6ebc5f81d1133f4aabaad70b1c is the first bad commit
commit 786fb38531e8be6ebc5f81d1133f4aabaad70b1c
Author: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Date:   Tue Sep 12 13:56:57 2017 -0400

    drm/amd/display: Refactor dc_update_planes_and_stream.
    
    Split update_planes_and_stream_state (split Software and Hardware
    programming) as the state is already build, so we only need to
    program the hardware
Comment 4 Harry Wentland 2017-10-31 20:57:38 UTC
Thanks for the bisect. Bhawan is looking at what in his change might have caused this.

How are you testing it? glxgears in fullscreen or some other app?
Comment 5 Andy Furniss 2017-11-01 00:32:54 UTC
glxgears is no good for this one, it doesn't seem to really get fullscreen.

I don't use a compositing window manager, if you do I guess you'll need to set it to disable compositing for full screen.

To seeing if I can get full screen tearing I would use something like - 

vsync720p60.mp4 - https://drive.google.com/file/d/0BxP5-S1t9VEEejRkMzlRck5GNTQ/view?usp=sharing

With no compositing and TearFree off I expect to see tearing playing like -

vblank_mode=0 mpv --vo=opengl -fs vsync720p60.mp4

For the frame rate capping issue I noticed with xonotic.

In the settings menu, video tab, make sure vertical synchronization is unckecked.
On the misc tab check show frames per second.

When on the menu screen fps should now be seen lower left.
For "bad" it's 120 for good it will be 200. Running a timedemo will also show being capped at 120 for "bad" but unlimited for "good".
Comment 6 Andy Furniss 2017-11-01 00:39:10 UTC
(In reply to Andy Furniss from comment #5)

> When on the menu screen fps should now be seen lower left.

ugh, it's lower right.
Comment 7 Michel Dänzer 2017-11-01 08:59:53 UTC
FWIW, I've been testing with glxgears, either

 glxgears -fullscreen

or making the window fullscreen manually. This may not work depending on the window manager, I'm using xfwm4 with compositing disabled for testing.
Comment 8 Bhawan Lakha 2017-11-01 17:07:30 UTC
Created attachment 135202 [details] [review]
Patch to fix vblank_mode not working properly

Please try this patch
Comment 9 Michel Dänzer 2017-11-01 17:15:57 UTC
(In reply to Bhawan Lakha from comment #8)
> Created attachment 135202 [details] [review] [review]
> Patch to fix vblank_mode not working properly

Tested-by: Michel Dänzer <michel.daenzer@amd.com>

P.S. I had to convert the patch from DOS- to Unix-style line terminators before applying it.
Comment 10 Bhawan Lakha 2017-11-01 17:20:33 UTC
Created attachment 135203 [details] [review]
Unix-style line terminators
Comment 11 Andy Furniss 2017-11-01 19:53:52 UTC
Patch is good for me as well, thanks.
Comment 12 Andy Furniss 2017-11-15 21:44:48 UTC
Fix is in mentioned kernels.

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.