| Bug ID | 103486 |
|---|---|
| Summary | Tonga DC vblank_mode=3D0 not working as expected fullscreen |
| 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 | adf.lists@gmail.com |
R9285, I notice that on both drm-next-4.15-dc and amd-staging-= drm-next, when using DC, vblank_mode=3D0 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 an= d amd-staging-drm-next, Which commit exactly of amd-staging-drm-next? > when using DC, vblank_mode=3D0 works windowed bu= t not properly full screen. >=20 > 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 rathe= r than > 1X. >=20 > 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=C3=A4nzer 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, >=20 > 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 poi= nter I first noticed on the version before that, while testing a different bug b= ut 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=3D0 works window= ed but not properly full screen. > >=20 > > Tried forcing TearFree from auto to off no difference. >=20 > That's expected; forcing TearFree on works around the problem though. = :) Ahh, so it does. I knew auto should =3D off for me, but it was worth being explicit. > > There is no tearing where it would be expec= ted - but it's not like it's just > > being ignored, a bench mark test will cap fps at 2X refresh rate = rather than > > 1X. > >=20 > > Maybe this is expected? >=20 > Definitely not, looks like there's been a regression affecting async f= lips. >=20 >=20 > > It doesn't happen with a months older DC kernel I have [...] >=20 > 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 comm= it 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 ge= t 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 -=20 vsync720p60.mp4 - https://drive.google.com/file/d/0BxP5-S1t9VEEejRkMzlRck5GN= TQ/view?usp=3Dsharing With no compositing and TearFree off I expect to see tearing playing like - vblank_mode=3D0 mpv --vo=3Dopengl -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 wi= ll 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 l= ower 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.
| What | Removed | Added |
|---|---|---|
| CC | bhawanpreet.lakha@amd.com |
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=C3=A4nzer <michel.daenzer@amd.com> P.S. I had to convert the patch from DOS- to Unix-style line terminators be= fore applying it.
| What | Removed | Added |
|---|---|---|
| Attachment #135202 is obsolete | 1 |
Created attachment 1= 35203 [details] [review] Unix-style line terminators
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |