GNOME Bugzilla – Bug 707537
Poor performance with high resolutions
Last modified: 2021-07-05 14:28:37 UTC
I recently put together a desktop system, and chose to run Gnome 3 on it, as it's what I'd become accustomed to on my laptop. I have an old Dell 2405fpw which I use for its display; it has a resolution of 1920x1200, compared to my laptop's 1600x900. On my laptop, gnome-shell generally runs smoothly, and I have no/few complaints. However, on the desktop system, gnome-shell is noticeably choppy. I'm unsure if there is any way to report an fps figure, but if I had to guess, I'd say it's significantly lower than 60 when dragging things in the overlay for instance. This is despite the fact that my laptop's sporting a sandy bridge i5, with HD3000 graphics, while the desktop is using an i7 4770 with HD4600 graphics (two generations newer). I recently added a second monitor to my setup, this time at a resolution of 1920x1080. This noticeably exacerbated the problem. Now dragging normal windows around the desktop is jerky compared to when only one monitor is enabled; dragging windows in the overlay is quite slow; etc. I realize that the HD4600 is not an astounding GPU, but struggling to just handle desktop interaction on these two monitors does not seem like a good situation to be in. For instance, displayport 1.2 is an option with this gpu, which can drive a 4K monitor, which will be the rough equivalent of four of the displays I'm using. Such monitors are beginning to be available, but I suspect gnome-shell will not work acceptably on them. (Even some tablets have higher resolution than the still-poorly-performing single monitor setup, probaby with poorer GPUs.) I also tried a KDE live CD to make sure the GPU was capable at some level, and as expected, KWin performs quite smoothly. I realize that KWin and gnome-shell probably do many things differently, but even the whole-desktop animations in KWin were quite smooth, while they are very choppy in gnome-shell. For some reference, my desktop specs are among the following: Intel i7 4770 CPU Intel HD4600 integrated GPU 32 GB RAM Arch Linux, kernel 3.10.10 Mesa 9.2.0 Intel xorg drivers 2.21.15 gnome-shell 3.8.3.1 It'd be nice to see Gnome working more smoothly in this setup.
Can you please run gnome-shell-perf-tool --perf-iters=3 --perf=core > perf.txt 2<&1 and attach the perf.txt file here?
Created attachment 254250 [details] output of gnome-shell-perf-tool Here's the requested file. Just to be clear, the shell is supposed to be left in an unresponsive state afterwards, correct? I ran the tool twice, because I wasn't sure if that was a lockup of some sort. I'll attach the second file, too.
Created attachment 254251 [details] second run of perf-tool Here's the second perf output.
(In reply to comment #2) > Created an attachment (id=254250) [details] > output of gnome-shell-perf-tool > > Here's the requested file. > > Just to be clear, the shell is supposed to be left in an unresponsive state > afterwards, correct? It is not *supposed* to do that but it does (which is a different bug).
OK so you indeed don't even hit 30fps it stays below 25fps most of the time. Does lowering the resolution and/or using just one monitor fix it? Can you try to disable powersaving for the GPU? Maybe it for some reason does not clock up ?
(In reply to comment #5) > OK so you indeed don't even hit 30fps it stays below 25fps most of the time. > Does lowering the resolution and/or using just one monitor fix it? By "fix it" I mean which numbers do you get in the perf output?
I won't be able to fully test things until this evening. However, I've done a bit of remote experimentation. If I watch /sys/class/drm/card0/gt_cur_freq_mhz during a run of the perf tool, it fairly quickly ramps up to ~1200, despite it started at the minimum 200. Looking at the perf output of these runs, though, I see vastly higher frame rates. 41-45 is the low point for the 10 maximized windows, but 5 maximized windows gets 60 fps and most other tests are 80-100 fps. I'm unsure what if anything has changed, though. I suppose it could have been stuck in a low power state (and is most of the time) and has since become unstuck. The only explanation I can think of at the moment is that in my search for the ability to watch the GPU frequency, I ran intel_gpu_top, which could have tweaked something that isn't normally tweaked. I'm a bit perplexed, though. I'll report back about resolution differences and such later.
(In reply to comment #7) > I won't be able to fully test things until this evening. > > However, I've done a bit of remote experimentation. If I watch > /sys/class/drm/card0/gt_cur_freq_mhz during a run of the perf tool, it fairly > quickly ramps up to ~1200, despite it started at the minimum 200. > > Looking at the perf output of these runs, though, I see vastly higher frame > rates. 41-45 is the low point for the 10 maximized windows, but 5 maximized > windows gets 60 fps and most other tests are 80-100 fps. I'm unsure what if > anything has changed, though. I suppose it could have been stuck in a low power > state (and is most of the time) and has since become unstuck. > > The only explanation I can think of at the moment is that in my search for the > ability to watch the GPU frequency, I ran intel_gpu_top, which could have > tweaked something that isn't normally tweaked. I'm a bit perplexed, though. Well just reboot and try again once without once with intel_gpu_top
Okay, I've done more testing. This definitely seems to be power saving related. Coming back after several hours, I observed the same poor performance as usual. However, now being able to monitor the GPU frequency, it was clear that it was staying in a low power state continuously. Even opening several full screen windows and dragging things in the overlay could only ramp up the GPU to around 500 MHz, and it was mostly lower than that, so about 1/3-1/2 of its full capacity. This was without rebooting by the way. By modifying gt_min_freq_mhz, I was able to force the GPU to run at full power continuously. And this made a huge difference. Gnome-shell is very smooth in such a state, even with both monitors enabled. And of course the perf tool confirmed, showing 60 fps in most cases (I'll attach a log). I also ran tests in both states with a single monitor enabled. The figures aren't much different. I'll attach output for those, too. The power behavior seems to be identical on my laptop, with HD3000 graphics. There the minimum frequency is 650 MHz and maximum is 1300. No matter what happens in gnome-shell, it doesn't seem to go above 700 MHz. But it seems that minimum power on HD3000 is capable of providing adequate performance for most loads on my 1600x900 laptop screen, while minimum power on the 4600 doesn't cut it for 1920x1200, let alone 1920x1200 + 1920x1080. So, I guess this is just overly aggressive power saving on Intel GPUs?
Created attachment 254317 [details] Performance output for one 1920x1200 monitor, automatic power saving.
Created attachment 254318 [details] Performance output for one 1920x1200 monitor, maximum GPU frequency forced
Created attachment 254319 [details] Performance output for dual monitors, high GPU frequency forced
OK, looks definitively like a driver bug then. I will try to point Intel people at this bug.
Oh and filing a bug at bugzilla.freedesktop.org (pointing to that one) wouldn't hurt.
(In reply to comment #13) > OK, looks definitively like a driver bug then. I will try to point Intel people > at this bug. OK, I have got some feedback can you build and test a kernel from this branch? http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=perf It is supposed to fix it.
<ickle> drago01: don't advise people to use intel-gpu-top on anything later than snb - it eats machines Make sure to never touch intel-gpu-top again ...
Noted. Thanks.
It occurs to me... I'm not sure how advisable it is for me to test the kernel in question. I have btrfs partitions, and I'm unsure if things have changed from 2.6.32 to 3.10.10 that would cause serious problems. I'll try putting together a standalone usb stick or something of the sort to test, but it will probably be a couple days at least.
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.