GNOME Shell Performance Improvements in Ubuntu 20.04

@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.

@lestcape,

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=i965
    

    in /etc/environment and 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-multiload if 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
    MESA_LOADER_DRIVER_OVERRIDE=i965
    
    in /etc/environment and 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.