Bug 109364

Please attach the Xorg log file, captured after reproducing the problem.

Created attachment 143136 [details]
xorg log

Here we go.

Does https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/24 fix it?

Situation seems to be unchanged with the PR.

Please attach a new log file from reproducing the problem with the patch applied.

Created attachment 143142 [details]
new xorg log

Please double-check that /usr/lib/xorg/modules/drivers/amdgpu_drv.so was compiled from the bugzilla-109364 branch in my xf86-video-amdgpu repository. While I'm unable to reproduce the problem with vkQuake, I was able to reproduce at least the first 3 messages with warzone2100, but not anymore with that change.

The last time I patched the PR into the main branch.
This time I directly cloned the specific bugzilla-109364 branch. TearFree unfortunately still breaks with it. It even makes the game's vsync not work correctly anymore, there is tearing then after switching it (the game's own vsync, not TearFree) on.

(In reply to tempel.julian from comment #9)
> It even makes the game's vsync not work correctly anymore, there is tearing
> then after switching it (the game's own vsync, not TearFree) on.

You know the drill. :) (Please attach the Xorg log file captured after reproducing these new symptoms)

I meant that this was also the case from the beginning, without the recent changes for this ticket (so case already covered by the existing logs).
I'll gladly test any further patches, but apart from that, I guess I can't provide anything more for this issue.

I rebased the branch on current master and expanded the fix, please re-test. If it still happens, please check the log file and attach it again if the TearFree / flip related warning/error messages changed.

It unfortunately still breaks with the same error reported in the log.

Btw: Did you test with radv? I once had similar issues only with TearFree + radv, but not amdvlk. I'll give the latter one a try again.

I'm testing with RADV.

I pushed a debugging patch to the branch, please reproduce the problem with that and attach the resulting log file.

With Git master, can you also reproduce the first 3 log messages with warzone2100, by toggling "Vertical sync" under Video Options? If so, does the branch also fix this for you?

The warzone2100 build provided by Arch unfortunately doesn't provide a Vulkan renderer, or do you want me to test it with OGL?

Created attachment 143149 [details]
xorg log with debug information

(In reply to tempel.julian from comment #15)
> The warzone2100 build provided by Arch unfortunately doesn't provide a
> Vulkan renderer, or do you want me to test it with OGL?

Yes, I doubt there is a Vulkan renderer, and it doesn't matter which application API triggers the bug(s).

I updated the debugging patch in the branch, please attach the log file from reproducing with that.

I tried with warzone2100, but for some reason the vsync setting in the options menu became unclickable after clicking it once.

So I tried the latest PR update with vkquake and to me it seems the errors logged haven't changed:

[    69.971] (WW) AMDGPU(0): flip queue failed: Device or resource busy, flip_pending=(nil)
[    69.971] (WW) AMDGPU(0): flipdata->fb[0]=0x56264548b8e0
[    69.971] (WW) AMDGPU(0): flipdata->fb[1]=(nil)
[    69.971] (WW) AMDGPU(0): flipdata->fb[2]=(nil)
[    69.971] (WW) AMDGPU(0): flipdata->fb[3]=(nil)
[    69.971] (WW) AMDGPU(0): flipdata->fb[4]=(nil)
[    69.971] (WW) AMDGPU(0): flipdata->fb[5]=(nil)
[    69.971] (WW) AMDGPU(0): scanout fb 0 = 0x56264548b8e0
[    69.971] (WW) AMDGPU(0): scanout fb 1 = 0x5626454f5d20
[    69.971] (WW) AMDGPU(0): Page flip failed: Device or resource busy
[    69.971] (EE) AMDGPU(0): present flip failed
[    69.971] (WW) AMDGPU(0): flip queue failed in amdgpu_scanout_flip: Device or resource busy, TearFree inactive
[    69.971] (WW) AMDGPU(0): flip_pending=(nil), scanout fbs = 0x56264548b8e0 0x5626454f5d20

(In reply to tempel.julian from comment #15)
> The warzone2100 build provided by Arch......

Maybe this bug is somehow related to this [1]?

[1] https://bugs.archlinux.org/task/58782

Have you tried xorg-server with autotools?

Thank you for the hint.
I tried building xorg with autotools, but the situation is unchanged for me.

(In reply to tempel.julian from comment #18)
> So I tried the latest PR update with vkquake and to me it seems the errors
> logged haven't changed:

That's bad news, as it means I'm running out of ideas how this condition might occur. :(

BTW, does it also happen with amdgpu.dc=0?

Yes, I think one of your changes introduced a difference between amdgpu.dc=1 and 0 in that regard:
With amdgpu.dc=0, TearFree remains enabled after switching vsync in vkquake on and off and then exiting the game. It just breaks the game's vsync when turning it from off to on, then there is tearing despite of the fps being locked to the refresh rate. Moving windows is still free of tearing after closing the game, unlike with amdgpu.dc=1. When I start vkquake again when I left the game's vsync enabled, it works without issues without having to re-enable TearFree again.

With amdgpu.dc=1, TearFree breaks "for good" after switching the game's vsync option, I have to re-enable TearFree then.

If we can't manage to find the root of the problem, perhaps automatically re-initializing TearFree after it detects failure would be a viable workaround?

Btw: It may be "helpful" to switch the vsync setting several times in vkquake to provoke the problem, not just once. The game also limits the fps by default to 72, I suggest using a value well above refresh rate (e.g. at least "host_maxfps 80" via the game's console or config for 75Hz).

Ok, the difference between amdgpu.dc=1 & 0 is also there with normal git-master of xf86-video-amdgpu.

(In reply to tempel.julian from comment #22)
> If we can't manage to find the root of the problem, perhaps automatically
> re-initializing TearFree after it detects failure would be a viable
> workaround?

I'd like to get to the bottom of these issues first, then I'll think about possible mitigation of similar issues in the future.

Please attach a log file from reproducing the problem with amdgpu.dc=0.


> Btw: It may be "helpful" to switch the vsync setting several times in
> vkquake to provoke the problem, not just once.

I've tried it several times.


> The game also limits the fps by default to 72, I suggest using a value well
> above refresh rate (e.g. at least "host_maxfps 80" via the game's console or
> config for 75Hz).

Are you saying you can't reproduce the problem with lower values?

Ok, it doesn't seem to matter if fps are capped below refreshrate by the game's fps limiter. However, it's easier to spot tearing when there is no judder due to repeated frames.

With amdgpu.dc=0 and TearFree not getting killed entirely by the vsync switch, the log is getting much longer. Not sure if it contains anything helpful though.

Created attachment 143198 [details]
amdgpu.dc=0 xorg log

Had another idea what could cause the problem. Branch updated, please re-test and attach the resulting log file (regardless of whether the problem still occurs).

I tried with amdgppu.dc=1 & 0 once each time, and it looks like you did it, no anomalies showed up. Yey! :)
Will test it a few more times to be sure.

Created attachment 143203 [details]
latest xorg log

Definitely fixed, thanks. I'd say TearFree works flawlessly here now.

I updated the branch with the final fixes for review, please test that it still fixes the problem. If any log message about drmHandleEvent appears during testing, please provide it.

It breaks again with the mentioned error in the log.

Created attachment 143226 [details]
drm handle error log

Ugh yeah, had a brain fart in patch 2. :} Fixed up now, please try again.

All fine again.

Fixes merged, thanks for the report and testing!

Really appreciate how well issues are sorted out for the xf86 DDX driver.
It'd be nice if the next release wasn't very far away, as there seem to be a lot of really helpful fixes included.

According to the 6-month release cycle, the 19.0 release is expected around March.