Gnome has a severe framedrop issue which makes it very unpleasant to use. Scrolling feels laggy and animations feel laggy as well due the drops. Running glxgears on a maximized windows shows the following
glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
300 frames in 5.0 seconds = 59.952 FPS
294 frames in 5.0 seconds = 58.720 FPS
297 frames in 5.0 seconds = 59.197 FPS
299 frames in 5.0 seconds = 59.775 FPS
264 frames in 5.0 seconds = 52.597 FPS
208 frames in 5.0 seconds = 41.600 FPS
237 frames in 5.0 seconds = 47.241 FPS
294 frames in 5.0 seconds = 58.633 FPS
279 frames in 5.0 seconds = 55.786 FPS
246 frames in 5.0 seconds = 49.200 FPS
208 frames in 5.0 seconds = 41.589 FPS
230 frames in 5.0 seconds = 45.851 FPS
230 frames in 5.0 seconds = 45.998 FPS
298 frames in 5.0 seconds = 59.418 FPS
214 frames in 5.0 seconds = 42.788 FPS
291 frames in 5.0 seconds = 58.058 FPS
There are no drops when doing the same on sway
glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
305 frames in 5.0 seconds = 60.957 FPS
301 frames in 5.0 seconds = 59.997 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.003 FPS
300 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.997 FPS
301 frames in 5.0 seconds = 60.003 FPS
300 frames in 5.0 seconds = 59.998 FPS
301 frames in 5.0 seconds = 60.002 FPS
300 frames in 5.0 seconds = 60.000 FPS
301 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.997 FPS
301 frames in 5.0 seconds = 59.999 FPS
301 frames in 5.0 seconds = 60.003 FPS
I have tested this on a fresh install without any extensions. Is this something that needs to be fixed by gnome/mutter or could this be a mesa related issue?
This is most likely unrelated to mesa. I can’t reproduce as extremely on a M2 13-inch Macbook Pro using mutter 44 / Fedora 38.
There are a few frame drops but the minimum I saw was 291 frems in 5 seconds (usually less than 1 dropped frame per second). This happens with es2gears_wayland as well so we can exclude Xwayland.
This is most likely an issue in mutter in combination with the apple silicon display driver. Since Apple has implemented parts of the display driver in firmware it the linux display driver has various peculiarities. These usually do not matter to wayland compositors as reaching the display refresh rate in sway and kwin_wayland shows.
It’s possibly that mutter expects something else/more.
This might be an issue with the Apple silicon display hardware/driver. The hardware doesn’t provide vsync interrupts (to the OS). This causes issue in X11 (animations run too fast). I wouldn’t rule out that frame timings as measured by mutter could depend on this. Another issue might be the split in GPU and display device. Those are two separate DRM devices. Bugs or other details against mutter’s expectations are of course possible as well.
Would you be able to/willing to comment on the mutter issue? It’s probably more productive to keep the discussion in one place instead of my copy pasting between the 2 issues.
Mutter doesn’t directly rely on vsync interrupts for timing. It does rely on the timestamps in page flip completion events though.
I doubt it’s directly related to the GPU/display device split. AFAIK mutter works fine on other platforms with the same split.
Another possibility is that either glGetInteger64v (GL_TIMESTAMP, ...) and/or glQueryCounter (..., GL_TIMESTAMP) reports an incorrect GPU timestamp, or that the two timestamps are inconsistent such that mutter calculates an incorrect wall clock time for when the GPU finished drawing a frame.
In summary, it’s more likely a Mesa/kernel driver issue than a mutter one.