Gnome 3.24.2 open/close animations have tanked in FPS

sitwano · 2017-09-21 17:33:39

I have recently reinstalled arch-linux due to some other problem. After the fresh re-install I am having a problem of gnome animations dropping frames too much. For example when I open terminal, the window fades in from the background with low fps. The same thing happens when I close the application, the terminal fades out but it is low fps. The overview and workspace switcher animations however seem to be smooth.

Session: Wayland
DE: Gnome 3.24.2
RAM: 7.6Gb
CPU: i5 5200U
GPU: Intel HD 5500
Mesa: 17.2.1-3
kernel: 4.13.2-1-zen

I am aware that xf86-video-intel/vesa has no effect on wayland session, so its safe to rule out that. I am stumped, as it was smooth just two days back. Could mesa be causing this issue? Will rollback mesa and check it out.

Everyone's feedback is welcome, especially if you notice same issue!

Update: Does not seem as though mesa rollback fixes it...

Last edited by sitwano (2017-09-21 20:07:03)

r3b311i0n · 2017-09-22 00:13:52

xf86-video-intel is not recommended https://wiki.archlinux.org/index.php/in … stallation

As for your issue, I'm not sure what's causing it.

seth · 2017-09-22 07:07:28

Does the rest of the screen update in desired pace (eg. run a video)
Is it actually "low fps" or is the animation just slow ("Look! I'm fading! Did you see the windows fade? Wait! Now I'm half gone! Isn't that cool?!!?!?!")

sitwano · 2017-09-22 08:28:49

I know its not recommended because i only installed it to check if it improved the situation.

@seth frames are definitely dropping because sometimes the animation is smooth and other times it's choppy. The animation itself seems to be drawn out for milliseconds more. I've already disabled all extensions.

Could anyone please tell me what gnome packages are responsible for animations? Is it just gnome-shell and mutter? Perhaps reinstalling from a different mirror would help coz they could be built with different options? Or do all the packages come from a single source repo? Idk this point.

Last edited by sitwano (2017-09-22 08:30:34)

mrunion · 2017-09-22 12:16:40

sitwano wrote:

...Perhaps reinstalling from a different mirror would help coz they could be built with different options?

Slightly OT, but I really doubt they are built with different options. They are mirrored -- as in copied from some single source to all the mirrors. The packages should be identical on every mirror.

Last edited by mrunion (2017-09-22 12:17:01)

seth · 2017-09-22 12:21:00

That's not what I meant - the question is whether *all* painting is choppy at this time (ie. dropping frames in a video)

Also watch the CPU load and whether you can spot a pattern on the affected windows.
This sounds more like a side-load on destroying the window.

cc:
- you did install and enable intel-ucode?
- tried the vanilla kernel?

sitwano · 2017-09-23 15:32:37

The really weird thing is that animations appear to be smooth in linux 4.9.51 LTS... So I think its a kernel issue. Something to do with the drm stuff.

update: I've filed a bug report for this at https://bugs.archlinux.org/task/55718 as this is not expected/normal behaviour.

Last edited by sitwano (2017-09-23 16:08:07)

seth · 2017-09-23 19:52:03

Just to be sure: you *did* test the non-zen mainline kernel on this and not the zen kernel against the lts one?

sitwano · 2017-09-23 20:57:36

seth wrote:

Just to be sure: you *did* test the non-zen mainline kernel on this and not the zen kernel against the lts one?

Apologies, I should have made it clear that I tested it with the zen kernel. 4.13.3 Arch kernel is not out of testing yet. I will report back once again after trying 4.13.3 arch kernel. However I doubt it would make much difference, although I agree that it is correct to rule out problem with zen.

Last edited by sitwano (2017-09-23 20:58:40)

loqs · 2017-09-23 20:58:54

If you could bisect between 4.9 and 4.12 and find a commit that is responsible then report that upstream. If it is a drm issue it is unlikely to be fixed before 4.15 then backported to 4.14 etc.
4.14 is also the targeted to be the next LTS kernel so if the issue is not resolved by the release of 4.15 linux-lts will likely move to 4.14 and all arch supplied kernels would then be affected by your issue.
If memory serves me correctly bisecting through 4.9 has additional issues as a large number of commits in that series did not boot because of broken CONFIG_MODVERSIONS and 4.9 will not build with gcc 7 without patching.

sitwano · 2017-09-23 21:17:30

Bisecting from 4.9 to 4.12 seems like a monumental task. I don't think I saw a similar problem with 4.11.x so I think I'll start from there. It would really help if other users who are experiencing this problem also help in bisecting.

Thanks for the feedback and comments so far! really appreciate the help.

loqs · 2017-09-23 21:24:04

You should be able to find older kernel packages in the Arch_Linux_Archive.

sitwano · 2017-09-24 09:49:34

I've narrowed the problem down to 4.12.1 kernel. The 4.11.9 kernel does not exhibit choppy animations.

There have been no drm/i915 commits since 4.11.9 to 4.11.13 so I am thinking those kernels would also show no problem. This is of course based on the assumption that only drm/i915 commits would cause poor graphics performance manifesting as choppy gnome animation.

Now the problem is I don't know the exact commit that causes somewhat poor animation performance in 4.12.1 kernel, since there are so many commits and multiple rc releases. I'm assuming the faulty commit has propagated down to the 4.12.14 kernel since then.

I really do not want to build each 4.12 rc release to find the culprit commit.

Any more advice?

Last edited by sitwano (2017-09-24 09:50:48)

loqs · 2017-09-24 10:16:13

$ git bisect start
$ git bisect bad v4.12
$ git bisect good v4.11
Bisecting: 7831 revisions left to test after this (roughly 13 steps)
[2bd80401743568ced7d303b008ae5298ce77e695] Merge tag 'gpio-v4.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

So assuming every bisect step yielded a clear good or bad result you would need to build 13 test kernels preferably 15 to double check the 4.11 and 4.12 you built locally.
The later builds would tend to be quicker as the amount of changes per step decreases so less code has to be rebuilt.

gedgon · 2017-09-28 13:52:03

Probably another p-state regression. Can you check a performance governor?

#echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

sitwano · 2017-09-28 15:28:15

gedgon wrote:

Probably another p-state regression. Can you check a performance governor?
#echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

So does this change the governer to become performance instead of powersave? I will check and report back!

sitwano · 2017-09-29 10:42:54

Update: Currently on 4.13.3 and performance governor does not make it any better. This is weird, since this is probably an i915 issue I am almost certain that most people with an integrated intel HD graphics would run into this issue.

Maybe gnome 3.24 is not using the GPU properly with the latest kernel?

Last edited by sitwano (2017-09-29 10:44:25)

V1del · 2017-09-29 10:49:59

Just to rule it out, because it has been the cause of a few issues lately, what happens if you boot with

intel_iommu=off

in your kernel parameters?

Last edited by V1del (2017-09-29 10:50:16)

sitwano · 2017-09-29 12:20:58

I added this to my /etc/default/grub file, ran sudo grub-mkconfig -o /boot/grub/grub.cfg and restarted. The issue persists.

Here are my kernel parameters:

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda2 quiet i915.enable_psr=0 i915.enable_rc6=1 drm.debug=0xe log_bug_len=2M intel_iommu=off"

Just to be clear, this is on 4.13.3-1-ARCH

There is probably one single commit in 4.12 series kernel. I am extremely inexperienced when it comes to bisecting kernels. Reading the https://www.kernel.org/pub/software/scm … isect.html document has left me with more questions than answers unfortunately.

To start off, please excuse me if I sound like a noob. I know this isn't the newbie forum catagory.

I am guessing to bisect, I need to do the following:
1.) Download the bleeding edge mainline kernel
2.) cd into the extracted folder
3.) git bisect start
4.) git bisect bad v4.12.1
3.) git bisect good v4.11.13
4.) What do I do next?

How does this process work? How do I speed up kernel compiling?

Last edited by sitwano (2017-09-29 12:54:00)

seth · 2017-09-29 12:40:55

I don't think this is (directly) related to the GPU. The effects itself should be cheap, the closing does not require buffer allocation - I think mutter/gnome-shell is doing something else which is related to a change of the window amount and running in the GUI thread (assuming mutter is MT)

Did you try the behavior on Xorg?
Do you have any custom extension enabled? (Anything taskbar/window/pager related?)

sitwano · 2017-09-29 13:07:29

seth wrote:

I don't think this is (directly) related to the GPU. The effects itself should be cheap, the closing does not require buffer allocation - I think mutter/gnome-shell is doing something else which is related to a change of the window amount and running in the GUI thread (assuming mutter is MT)
Did you try the behavior on Xorg?
Do you have any custom extension enabled? (Anything taskbar/window/pager related?)

Thanks a lot for this suggestion. I don't know why I didnt try xorg yet to see if it happens.

So in xorg session the application open/close animations are smooth again. However every other animation such as window overview animation is sluggish/low fps (but not as bad as the stuttering animation mentioned in wayland), but that was always the case (I think). But this asks the question "Why is gnome open/close animations under wayland somewhat broken in 4.12/13 kernel and not 4.9-LTS?"

Thanks again for your suggestions!

btw is the xf86-video-vesa driver meant to be used for intel integrated HD graphics? I know that the xf86-video-intel is not recommended, but theres little to no information on the vesa driver and I dont know what it is used for, unfortunately.

Last edited by sitwano (2017-09-29 13:14:01)

seth · 2017-09-29 21:08:27

You can use the vesa driver, but it will provide only limited features and no HW acceleration.
VESA is a 20 year old standard that virtually every device built afterwards supports - it's a failsafe.

Use either the modesetting or the intel driver (the latter might still perform better than the modesetting driver in certain constellations)

loqs · 2017-09-29 22:14:56

sitwano see https://bbs.archlinux.org/viewtopic.php … 5#p1700245 for step by step instructions on how to bisect the kernel.
You could bisect between two stable kernels if you use the tree git+https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git but it might be easier to just bisect between 4.11 and 4.12
You just need to adjust the PKGBUILD to use the .config from 4.11 or 4.12. For speeding up the process https://bbs.archlinux.org/viewtopic.php … 8#p1700408

Arch Linux

#1 2017-09-21 17:33:39

Gnome 3.24.2 open/close animations have tanked in FPS

#2 2017-09-22 00:13:52

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#3 2017-09-22 07:07:28

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#4 2017-09-22 08:28:49

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#5 2017-09-22 12:16:40

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#6 2017-09-22 12:21:00

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#7 2017-09-23 15:32:37

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#8 2017-09-23 19:52:03

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#9 2017-09-23 20:57:36

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#10 2017-09-23 20:58:54

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#11 2017-09-23 21:17:30

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#12 2017-09-23 21:24:04

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#13 2017-09-24 09:49:34

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#14 2017-09-24 10:16:13

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#15 2017-09-28 13:52:03

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#16 2017-09-28 15:28:15

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#17 2017-09-29 10:42:54

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#18 2017-09-29 10:49:59

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#19 2017-09-29 12:20:58

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#20 2017-09-29 12:40:55

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#21 2017-09-29 13:07:29

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#22 2017-09-29 21:08:27

Re: Gnome 3.24.2 open/close animations have tanked in FPS

#23 2017-09-29 22:14:56

Re: Gnome 3.24.2 open/close animations have tanked in FPS

Board footer