Bug 2188449

Does

 gpu_sched.sched_policy=0

on the kernel command line make any difference?

Hello Michel, 

thank you for the fast reply!

Sadly, this did not improve it but I also noticed something new. Not just the 3d application, but also the mouse cursor gets stuttery/jittery. It basically mimics the behaviour of the 3d application. When I close the 3d application, the cursors moves smoothly again. I could see this while running unigine superposition in windowed mode. Using fullscreen does not change anything.

I also tried the X11 Session of Gnome and the issue still persists. So it is not bound to the Wayland session.

Can you see if https://koji.fedoraproject.org/koji/taskinfo?taskID=100209917 makes a difference? It has some experimental patches applied that changes how X11 windows are managed. Note, there might be bugs causing glitchyness etc so be prepared for that.

I will try that. I also did some tests with other games. It seems, that flatpaks are less susceptible to this issue. I also found out that xonotic for example has no issue with stuttering or jitter. There are just some small occasional hangs, which is not optimal, but usable.

I tried the linked package and it did not improve the stuttering. What it did was removing the black squares that got sometimes rendered first when opening an application so it is better than before. Is there some kind of debug information I could gather to make tracking down the issue easier? If yes, how can I do it?

When running the game in fullscreen mode, alt tab to a terminal, run

    sleep 5 && xwininfo -root -tree >& xwintree.txt

and quickly (within 3-4 seconds) alt tab back to the game. Wait for a few seconds, then upload the xwintree.txt file.

I uploaded three log files.

One was with Unigine Superposition Fullscreen, one with Unigine Superposition Windowed and one with Wreckfest Fullscreen. Superposition in Fullscreen was actually pretty okay, but Wreckfest in Fullscreen and Superposition Windowed were really bad.

Created attachment 1958820 [details]
Wreckfest Fullscreen

Created attachment 1958821 [details]
Superposition Windowed

Created attachment 1958822 [details]
Superposition Fullscreen

Was that with the scratch build installed, then you logging out and in again? The way windows are managed when windowed seems to be how they work with what is currently the version in F38.

Anyhow, the suspicion I had was that some window management changes related to window decorations would be the cause of at least the issues when running fullscreen, and that the scratch build would fix the issue if so was the case, but looking at the attached files, it doesn't seem to be that. In the fullscreen case, both Superposition and Wreckfest both have their windows completely undecorated, thus are both unaffected by the window decoration changes between F37 and F38.

No, this was with the build from the fedora repositories. I will redo the testing the patched version.

(In reply to klaus.semmler from comment #3)
> I also tried the X11 Session of Gnome and the issue still persists.

Does it affect the mouse cursor in that case as well?

@mdaenzer yes it does.

(In reply to klaus.semmler from comment #15)
> @mdaenzer yes it does.

Sounds like a kernel issue then. If you still have an old kernel from F37 lying around, might be interesting to try that.

I sadly do not have an F37 Kernel around anymore. Is there another possibility to use an older kernel aside from compiling?

Created attachment 1958857 [details]
Wreckfest Fullscreen Scratch Build

Created attachment 1958858 [details]
Superposition Fullscreen Scratch Build

Created attachment 1958859 [details]
Wreckfest Windowed Scratch Build

@jadahl I attached the logs created with the mutter scratch build.

Thanks, that confirms that the behavior is the same with and without, and that it's not related to the decoration changes.

@mdaenzer I retested X11 and the cursor is not stuttering there so I think the kernel is not the culprit. Sorry for posting the wrong information!

@

@jadahl Can I install the repository version of mutter again or is the scratch build still necessary for testing? And sorry for the empty comment! My browser decided to just send this comment oO.

You can install the repository version again.

Is there any other data I can provide to help out?

Can you try this:

1. Press Alt-F2
2. At the prompt, enter "lg"
3. In the debug window which pops down, go to the Flags tab, scroll down to ClutterDrawDebugFlag and enable PAINT_DAMAGE_REGION
4. Press Esc to close the debug window

You should now see areas of the desktop getting updated flashing in red/green. If so, does any part of the screen flash in red/green while the test apps are fullscreen?

(Use the same procedure to disable PAINT_DAMAGE_REGION again)

The fullscreen apps are not flashing in any color. It seems odd to me, that the apps are smooth with vsync enabled and stuttery/jittery without vsync.

(In reply to klaus.semmler from comment #29)
> The fullscreen apps are not flashing in any color.

To be clear, the desktop is flashing while no app is fullscreen though, right?

> It seems odd to me, that the apps are smooth with vsync enabled and stuttery/jittery without vsync.

Indeed, and it's still pointing to a kernel issue, at least in the fullscreen case. mutter 44 explicitly waits for the GPU to finish drawing to client buffers before using them for direct scanout, but the amdgpu kernel driver seems to fail to update the HW cursor & scanout buffer for the next display refresh cycle for some reason.

Yes, the desktop and the apps on it flash. Mostly red. Are there some logs from the kernel driver that could help with debugging?

The apps in fullscreen did not flash, just to be clear.

As a debugging measure, I tried to force the high dpm power state to force the maximum clock speed with the following command:

echo high > /sys/class/drm/card1/device/power_dpm_force_performance_level

This had no effect on the issue sadly.

The next thing I treid was to disable resizable bar in the bios of my system. This also did not yield any improvement.

I now tried to reproduce the issues when running Unigine Superposition from an Live ISO. I first tried the KDE Spin to see if the issue still occurs. And interestingly the issue did not occur. With KDE, the rendering was always smooth. Windowed and in Fullscreen. I then tried the Workstation ISO with Gnome as default desktop. With the workstation ISO I could reproduce the stuttering I encounter on my desktop. As the kernel and mesa packages were the same on both ISOs, I think the issue is not the kernel but the compositor or desktop.

I now took some time to install KDE on my PC and had mixed results. On one Hand Unigine Superposition is smooth like in the Live ISO, but Wreckfest is still stuttery/has microstutter. Sometimes it is smooth, but on other parts of an track, it stutters. Different proton versions did not change anything. Using VSync still fixes this problem. Now I am out of ideas on what to test further.

As my Vega 56 seemed to be defective as it shut down for no reason quite often, I replaced it with an Radeon RX6600. Sadly the issues still persist.

Would profiling Unigine Superposition with an app like Sysprof help to track down the issue?

@mdaenzer Sorry for the noise but I actually have some interesting debugging results.

I tested the Fedora 37 Live Media with kernel 6.0.7 and everything rendered smoothly, no stuttering whatsoever.
Then I tested Manjaro 22.1 with kernel 6.1.25 and here again everything rendered smoothly.
Then, as a control, I tried Ubuntu 23.04, which also used kernel version 6.2 like Fedora 38 and the stuttering/jittering was back.

So this issue got introduced with kernel version 6.2 and is not isolated to Fedora as Ubuntu has the same issue.
I therefore changed the affected component from mutter to kernel as the issue seems to be introduced with kernel version 6.2.

(In reply to klaus.semmler from comment #39)
> So this issue got introduced with kernel version 6.2 and is not isolated to
> Fedora as Ubuntu has the same issue.

Sounds like https://gitlab.freedesktop.org/drm/amd/-/issues/2516 then.

The fact that gpu_sched.sched_policy=0 on the kernel command line doesn't help indicates that there was a second regression separate from the commit identified there. Bisecting the kernel between 6.1 & 6.2 with gpu_sched.sched_policy=0 on the kernel command line should allow identifying that second regression.

Ah, good to know there is already an open issue. Sadly I never had bisected kernel issues and don't know how to do it. Also the pc with this issue is my main pc and ending up bricking it would be problematic.

@mdaenzer I tried a fedora rawhide live image with the 14th may as the build date with linux kernel 6.4.0 RC1 and the issue still persists.

(In reply to klaus.semmler from comment #42)
> @mdaenzer I tried a fedora rawhide live image with the 14th may
> as the build date with linux kernel 6.4.0 RC1 and the issue still persists.

That's not surprising, since no fix has been proposed, nor has there been any more information about which specific commit between 6.1 & 6.2 introduced the issue (see comment 40).

If I am not mistaken, there seems to be a fix for this on the mesa side of things, if I understand this correctly:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23965

I found this MR here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9189

Would like to test the mesa patch, but I don't want to bork my work setup.
 A copr repository would simplify testing a lot and would make a rollback very easy.

(In reply to klaus.semmler from comment #44)
> If I am not mistaken, there seems to be a fix for this on the mesa side of
> things, if I understand this correctly:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23965
> 
> I found this MR here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9189

That issue was bisected to a change which landed in kernel 5.18/5.19, so it's unlikely to be the same issue as this.

If if was, running the game with the environment variable `radv_zero_vram=false` should give mostly the same performance benefit as the Mesa MR above (assuming the game uses Vulkan).

After the update to Mesa 23.1.5, the issues improves a bit. Now Superposition has good Framepacing in Fullscreen and borderless window mode. Only in windowed mode it has still terrible framepacing. Other games like Wreckfest did not improve. I will try to bisect the issue when time allows it. Sadly that is not the case currently, but at least the mesa update improves stuff a bit.