@vanvugt, the video stutter is because of the indicator-multiload or this is because the server side of the indicator-multiload is running inside the compositor thread? It’s true that the indicator-multiload is heavy and is also true the Ubuntu implementation of the indicator is really questionable right now as this is happening for all images that AppIndicator receive in the gjs side (https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/005fe8b8280c2bdb65fa5927de2e2ed60def0480/appIndicator.js#L477-L490). But a video stutter should not happens if the indicator-multiload will be running outside the compositor.
I know I am repetitive, but it is repetitive to see how the 3rd parties apps are blamed for the bad architecture of the shell. Isn’t it a good idea to finish fixing the shell architecture at once? i.e.: I think all GUI process should be moved outside the compositor thread. I’m pretty sure at less a video stutter should not occurs in that way. Thanks for sharing all the shell progress and your own work on this.
On a 4k monitor, firefox playing 4k youtube video stutters… whereas in Unity it is smooth.
So, it’s not just the problem of bug 784055 , something different to Unity is happening to the issue reporter in gnome-shell. That “something” is the point of my comment.
Edit2: To reproduce the reporter issue, just create an extension that execute an spawn command line in sync mode every 1 seconds (for example). Then open a video in firefox and you will see the video stutter. The spawn_command_line_sync it is slow enough to slowdown the compositor thread and it cause a stuttering. Any delay in the compositor thread tends to create the same effect. The indicator-multiload is complex, so it enough the delay that it introduced in the compositor for the bad effect of stuttering to occur. Of course, executing spawn_command_line_sync in a gjs application, outside the compositor thread does not generate the problem at all.
Please keep that discussion in bug 784055. Yes I agree it sounds like the shell is to blame and you can see I made changes in the bug to that effect on 2020-03-14. Nobody has had time to look into it yet – it’s a fairly new (re)discovery that gnome-shell is badly affected…
Is 3.36.4 expected to be merged soon into 20.04? I would like to test the effect of the backported culling fixes and I could either wait for 20.04 to include them or install Arch just to see, depending on the ETA.
Marco is working on 3.36.4 right now. That said, most of the performance work I’ve done recently is not in that. I’m still in a mad rush trying to make sure it all gets into 3.38.
Thanks for letting us know @vanvugt , I know there has been a lot of improvements besides that one, but I still have some expectations that my 4K monitor will noticeable improve performance with the backported fix and so I’ll stay in the LTS version. If not, well, I will upgrade to 3.38, it’s not a big deal anyway.
Sadly this is not making much of a difference per se, at least for me, I did the override and dmidecode -t17 lists a couple of memory devices, so I assume dual channel is enabled, but there still is stuttering, specially with kernel 5.4. I will let you know what happens after I upgrade to 3.36.4. Thank you for tip, anyway! I’m following the mesa issue and looks promising.
The improvements will come in 3.38. There is little point discussing 3.36.4. Although if I do backport any improvements to 3.36 in future then I will announce it.
I have also been waiting for 3.36.4 to land in focal-updates. Also 4K here (Dell XPS 9570).
I’ve been getting these stuttering spikes.
One minute I’m watching a video (SMPlayer full screen on external monitor and some terminals with stats on the built-in laptop monitor). Everything good, the Render/3D/0 shows load around 90%, but the frequencies (at the top of the intel-gpu-top's output) are around 400/400.
Then, with no apparent reason, the frequencies change to 100/1200, and Render/3D/0 jumps to 100% (Blitter/Video/VideoEnhance remain at 0). The video is stuttering heavily. If I close it (or minimize), wait for some time and continue, it doesn’t stutter anymore for a while, and then the problem returns. The CPU temps are okay during all that, nothing indicates throttling.
I figured Firefox can take a lot of CPU/rendering power and the culling should help, but minimizing all of the background applications doesn’t help. Nor does disabling all the extensions.
Please don’t expect any significant performance gains in 3.36 soon. I am focussed on 3.38 and we can’t get anything into 3.36 without it being in 3.38 first.
If you need better performance right now then I suggest:
Remove all gnome-shell extensions that didn’t come from Ubuntu. We find a large number of performance problems (and general bugs) are caused by extensions that users have installed themselves.
Check your log (journalctl -f) and if any messages are repeating then log a new bug about that. But please don’t waste time logging bugs if you still have any custom extensions installed. Those should be removed as a first step.
If your Intel GPU is more than a year or so old then you will benefit from forcing the Intel driver to the older one that is more proactive with frequency scaling. Just add
Remove all gnome-shell extensions that didn’t come from Ubuntu.
Is removing them necessary, or does disabling them (for the duration of testing) usually help just as well? I only have a few, and disabling them didn’t change anything WRT performance.
Disabling an extension should be sufficient in most cases. However disabled extensions still get loaded in a way, so a buggy extension can still affect you even when it’s disabled.
FWIW, looking at the description of that bug report, I’ve seen GNOME Overview stutter similarly for as long as I can remember. It doesn’t hurt the functioning of the programs otherwise, so I usually ignore it.
TBH for the time being I prefer to just turn off animations. But I was wondering if there is any chance for !1383 to be included in 3.38, given that gnome already is at some freezing stage. Or maybe you plan to patch mutter downstream, specially considering that for now it’s an X11 only solution. Moreover, is there any reasonably simple way to build mutter with !1383 at this point, Daniel? Just to check if it’s indeed an improvement in my case, since for the last three major releases I was hoping for this or that optimization to finally fix it but it becomes clear now that it’s better to check that beforehand, which AFAICS is not an easy thing to do when it comes to shell/mutter.