@ramrajcg, that sounds like a problem we would like to solve. Please open a bug from the affected machine by running:
ubuntu-bug gnome-shell
so we can investigate it further.
Edit: Discussion moved to bug 1879604
This is the first release that I feel comfortable pointing people to and saying āthis is Linux, go!ā. Thank you folks for all the hard work youāve done to make it as good as it is.
1 Like
@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.
Edit: In the title of bug 1879604 it said:
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ā¦
2 Likes
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.
2 Likes
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.
2 Likes
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.
Pro tip: You can boost performance at 4K without waiting for the software updates using the two methods I am using on my 20.04 machine:
-
Make sure you have dual channel RAM installed (using both channels). Check it by running:
sudo dmidecode -t17 -
Force Mesa to use the old driver which seems to be more aggressive with frequency scaling (in a good way):
MESA_LOADER_DRIVER_OVERRIDE=i965in
/etc/environmentand reboot. But I aim to fix this properly in 3.38 so you donāt need to revert to the old driver.
3 Likes
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.
@memeplex, I suggest you log a bug from the affected machine so I/we can see the details of the machine and can then make suggestions tailored to you:
ubuntu-bug gnome-shell
I have a 4K display on my ThinkPad and I donāt have any performance issues. I will run that command and see if I notice anything different.
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.
-
Remove
indicator-multiloadif you happen to have that. - 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
inMESA_LOADER_DRIVER_OVERRIDE=i965/etc/environmentand then reboot.
2 Likes
Thank you, Daniel.
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.
1 Like
Indeed I have tried 3.36.4 in Arch and the improvements were marginal. Fingers crossed for !1383 then.
Please follow the instructions I mentioned above. If performance still isnāt good enough then please open a bug by running:
ubuntu-bug gnome-shell
so I can analyse your system in detail.
Sadly none of the above helps, so here is my report. Thanks!
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.
Using Intel HD 630, 1-2 4K screens and Xorg.