Bug 103486

(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.

(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.

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

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?

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".

(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.

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.

Created attachment 135202 [details] [review]
Patch to fix vblank_mode not working properly

Please try this patch

(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.

Created attachment 135203 [details] [review]
Unix-style line terminators

Patch is good for me as well, thanks.

Fix is in mentioned kernels.