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