After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776950 - gnome shell 30fps max animations with intel gpu
gnome shell 30fps max animations with intel gpu
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-01-06 15:17 UTC by groucho
Modified: 2021-07-05 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description groucho 2017-01-06 15:17:15 UTC
Hello,
I have been using debian jessie since it came out and enjoyed a 60fps experience with gnome. But since I tried debian stretch, it felt less smooth.

I have benchmarked the performance with 
CLUTTER_SHOW_FPS=1 gnome-shell --replace
and set St.set_slow_down_factor(20) in lg.

I have measured the activities animation, since it is one of the animations that I see the most when I use Gnome.

Debian Jessie uses UXA and DRI2 by default and the animations were at 60fps.
I have checked with the most recent driver in jessie backports, and the 60fps were gone. It was 30fps at best.
I have made a bisect, and found out that the regression was introduced by the commit :
xf86-video-intel
6db906ea8188cd7f731e5ef7391115ee8f5c17c8
uxa/dri2: Reimplement triple buffer support

Now, with debian stretch (I have also checked fedora and arch), SNA, UXA, DRI2, DRI3, modesetting, all feel the same :
- 60fps when moving windows, and fade in/out animations (the calendar, for example)
- but everything else is capped at 30fps max (activities, changing desktop, showing applications,...).

I can't benchmark wayland, but it felt exactly the same.


My machine was obviously capable to render all animations at 60fps with debian jessie (also no problem with compiz and kwin, even with 10+ windows) and with the latest drivers gnome shell can render some animations at 60fps.
Comment 1 groucho 2017-06-04 12:55:53 UTC
Silly me, there is a perf tool for that (doesn't work on Wayland though).

These are the results before the commit:

# Frames rate when going to the overview, 10 alpha-transparent windows open
overviewFps10Alpha 57.1958508496
# Frames rate when going to the overview, 10 maximized windows open
overviewFps10Maximized 55.6326022944
# Frames rate when going to the overview, 10 windows open
overviewFps10Windows 57.4456144692
# Frames rate when going to the overview, 5 alpha-transparent windows open
overviewFps5Alpha 59.5006703742
# Frames rate when going to the overview, 5 maximized windows open
overviewFps5Maximized 63.1220148547
# Frames rate when going to the overview, 5 windows open
overviewFps5Windows 59.9046318261
# Frame rate when going to the overview, first time
overviewFpsFirst 60.7995136039
# Frames rate when going to the overview, second time
overviewFpsSubsequent 61.0242306879


And these are the results after:

# Frames rate when going to the overview, 10 alpha-transparent windows open
overviewFps10Alpha 23.271418431739114
# Frames rate when going to the overview, 10 maximized windows open
overviewFps10Maximized 24.078399268016664
# Frames rate when going to the overview, 10 windows open
overviewFps10Windows 23.188853890896443
# Frames rate when going to the overview, 5 alpha-transparent windows open
overviewFps5Alpha 28.9440387684725
# Frames rate when going to the overview, 5 maximized windows open
overviewFps5Maximized 29.45074363127669
# Frames rate when going to the overview, 5 windows open
overviewFps5Windows 30.20155764533556
# Frame rate when going to the overview, first time
overviewFpsFirst 33.18856796070474
# Frames rate when going to the overview, second time
overviewFpsSubsequent 36.14858514437745


I also had to disable DRI3 at some point during the bisect.



I am still not sure if it is a driver issue or a Gnome issue.

But Gnome was only fluid with UXA DRI2, while kwin and compiz are fluid with every settings, before and after the commit.
Also, moving windows and other animations hit 60fps.

It seems to me that there is something wrong when Gnome is calculating animations ticks during the overview animation.

Wayland feels the same.


My GPU is a first gen I5, but it seems a lot of other Intel GPU owners are complaining about this issue.

I have no problem on NVIDIA machines.
Comment 2 groucho 2018-07-10 15:43:04 UTC
I have been following the work of Daniel van Vugt and have tried some of his patches.

The overview and swarm animations are much better if I modify mutter/clutter/clutter/cogl/clutter-stage-cogl.c like so:
  - in function clutter_stage_cogl_schedule_update
    returning with stage_cogl->update_time = 0;
  - in clutter_stage_cogl_get_update_time
    removing the return -1;


Here are the benchmarks with modesetting:
# Time to switch to applications view, first time
applicationsShowTimeFirst 814080
# Time to switch to applications view, second time
applicationsShowTimeSubsequent 799353
# Additional malloc'ed bytes the second time the overview is shown
leakedAfterOverview 3524064
# Frames rate when going to the overview, 10 alpha-transparent windows open
overviewFps10Alpha 39.569288296888374
# Frames rate when going to the overview, 10 maximized windows open
overviewFps10Maximized 46.412865646357176
# Frames rate when going to the overview, 10 windows open
overviewFps10Windows 45.70314285279018
# Frames rate when going to the overview, 5 alpha-transparent windows open
overviewFps5Alpha 52.82922512734045
# Frames rate when going to the overview, 5 maximized windows open
overviewFps5Maximized 3.4688617623899067
# Frames rate when going to the overview, 5 windows open
overviewFps5Windows 44.77879276374709
# Frame rate when going to the overview, first time
overviewFpsFirst 55.03072548839769
# Frames rate when going to the overview, second time
overviewFpsSubsequent 57.83164382316736
# Time to first frame after triggering overview, first time
overviewLatencyFirst 233696
# Time to first frame after triggering overview, second time
overviewLatencySubsequent 117871
# Malloc'ed bytes after the overview is shown once
usedAfterOverview 66337904


As a reference, here are the results with no modifications:
# Time to switch to applications view, first time
applicationsShowTimeFirst 815318
# Time to switch to applications view, second time
applicationsShowTimeSubsequent 846448
# Additional malloc'ed bytes the second time the overview is shown
leakedAfterOverview 3690112
# Frames rate when going to the overview, 10 alpha-transparent windows open
overviewFps10Alpha 18.389029105235817
# Frames rate when going to the overview, 10 maximized windows open
overviewFps10Maximized 20.868440136270916
# Frames rate when going to the overview, 10 windows open
overviewFps10Windows 21.680686844159222
# Frames rate when going to the overview, 5 alpha-transparent windows open
overviewFps5Alpha 21.805209700701692
# Frames rate when going to the overview, 5 maximized windows open
overviewFps5Maximized 10.249388111529742
# Frames rate when going to the overview, 5 windows open
overviewFps5Windows 21.859739169592228
# Frame rate when going to the overview, first time
overviewFpsFirst 27.309570365839004
# Frames rate when going to the overview, second time
overviewFpsSubsequent 32.138839787883654
# Time to first frame after triggering overview, first time
overviewLatencyFirst 196672
# Time to first frame after triggering overview, second time
overviewLatencySubsequent 107847
# Malloc'ed bytes after the overview is shown once
usedAfterOverview 65960016



It is not as fluid as it used to be, so I still don't know if it is a problem in the skipping frame mechanism, or if the Intel driver doesn't send the right signal. Or if it is a combination of both.

Hope this helps someone who has more skills than I have.
Comment 3 GNOME Infrastructure Team 2021-07-05 14:30:52 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.