high cpu when sddm-greeter is idle

[jpsinthemix]

I'm playing around with kf5 and would like to use sddm. I build all packages (similar to lfs) and while sddm appears to be functioning, there are several issues which are show-stoppers in my judgement. I'll focus on one here: once sddm-greeter has started and is simply idling, waiting for user login (the password entry field has focus), sddm-greeter shows an alarmingly high cpu usage. In particular, by theme, we have: breeze .. 5-10 % cpu maui ..... 60-80 % cpu circles ... 20-27 % cpu

Observations:

• once logged in, cpu usage drops to 0-0.7 % cpu
• in the maui theme, if I do not set focus: true in the listview element, then sdd-greeter will start up without the password field having focus, and we get 0 % cpu; but as soon as I click on the password field, cpu usage goes to 60-80 %
• in the maui theme, if I remove the clock from Main.qml, we get 23-28 % cpu

Systems: All are i686-pc-linux-gnu, with qt-opensource5.5.3.2, gcc-4.9.2, glibc-2.20, linux-3.17.4, and systemd-217 All exhibit the same behavior, same cpu usage One system uses llvmpipe, one uses i915/opengl 2.1, and another a radeon x1400/opengl 2.1

It looks kinda like something is triggering qt/qtquick to do screen updates frequently and unnecessarily. Has anyone else seen this kind of behavior ?

[tsjk]

I have observed the same phenomenon. On an up to date Arch Linux i686 system, running on an Asus eee901 with a linux-pf kernel. I run the 0.11 release provided by the distribution. Changing the focus attribute fixes the issue of high cpu usage on greeter start up. But yes, as soon as the password field is focused the usage goes up.

[jpsinthemix]

My initial post was for sddm-0.11.0.20141120.09c161b. I've also built sddm-0.9.0 which builds against qt4/qtquick1 rather than qt5/qtquick2. While the idle cpu usage is lower for the latter (maui is 40% instead of 60%), it is still ridiculously high. This is definitely a show-stopper for me.

[jpsinthemix]

Additional info if any one cares..

The sddm-0.9.0/qt4/qtquick1 excessive-cpu usage issue is fixed by enforcing use of opengl (apparently the default is xrender based); presumably there is a qtquick1 event-loop bug when opengl is not used, but there seems to be little point in pursuing the issue.

The sddm.0.11.0.20141207.fe4ada1/qt5/qtquick2 excessive-cpu issue is different. The bug is in qquicktextinput.cpp and related code (and present in qquicktextedit.cpp and related code as well); a significant portion (if not all) of the greeter window is updated on each change of cursor state (each blink), hence the elevated cpu usage. Its easy enough to embed debug in the qt code to see this. Interestingly, as a test, one can run a really simple qml file which simply displays a textinput field with a png border. When the field does not have focus, 0% cpu, with focus, 0-1.3% cpu (already too high for such a simple window), and as one types characters the cpu usage climbs with each additional character, eg, after typing in 20 characters the cpu usage rises to 7-9% and stays there. This is rather sad with Qt5 now at version 5.4. With performance like this its no wonder they've decided to no longer support opengl 1.x (which I find obnoxious and infuriating).

[jleclanche]

I finally managed to reproduce this on one of my lower-grade machines.

[jpsinthemix]

I looked into this a bit more a while ago, and put it on hold for the time being. This is not an sddm bug, but simply due to the qtquick2 scenegraph implementation, particularly the use of shaders too complex for older GPUs to handle. GPUs with limited opengl 2.0 functionality (specifically, limited shader capability) will either not work at all or exhibit extremely poor performance with QtQuick2. For example, Thinkpad R51's using the i915 driver (with marginal opengl 2.0 support) show very poor performance: only 1-3 texture calls are supported in a shader; if a shader has more texture calls, swrast calls are triggered-- leading to the poor performance.

As a quick (Qt-5.4.0) workaround, one can set the Qt (subpixel anti-aliasing text rendering) environment variable QSG_DISTANCEFIELD_ANTIALIASING=subpixel-lowq, eg, QSG_DISTANCEFIELD_ANTIALIASING DEFAULT=subpixel-lowq in /etc/security/pam_env.conf.

The default Qt5Quick anti-aliasing shader employs the shader pair hiqsubpixeldistancefieldtext.{vert,frag} which has more than 3 texture calls, whereas 'subpixel-lowq' uses loqsubpixeldistancefieldtext.{vert,frag} which has fewer calls. This is likely only a temporary 'fix' since presumably QtQuick, KF5, and others will increasingly make use of shaders too complex for most older GPUs. Currently (as of Qt-5.4.0), Qt5Gui and Qt5Declarative (QtQuick1) will still work fine on GPUs with opengl <= 2.0, but this is of little value to end-users since kframeworks and others would have to implement this support along with QtQuick2 support, which they apparently have no interest in doing.

[plfiorini]

Mmmm unfortunately I don't think there's much we can do here.

[plfiorini]

@jleclanche How much lower grade?

[katanacrimson]

@plfiorini I have a cr48 and was encountering this, if that helps. It's a little Intel Atom in there, so intel gfx.

[jleclanche]

@plfiorini first gen asus eee :p

[jleclanche]

Intel gfx as well on it.

[tsjk]

I observed this on a ASUS EeePC 901. Intel GFX on that too. Since then I've installed KitKat on that machine, so I for one do not care anymore.

[hogend]

On a core i5 4570, sddm-greeter takes between 3 and 6% CPU (breeze theme) when idling. This is IMNSHO insane. Please, fix this to stop global warming.

[katanacrimson]

@hogend Can you state what GPU, for the record?

[hogend]

The internal GPU, which is an Intel HD Graphics 4600.

Regards,

Rene

From: Damian Bushong [mailto:[email protected]] Sent: Wednesday, September 02, 2015 1:35 AM To: sddm/sddm Cc: hogend Subject: Re: [sddm] high cpu when sddm-greeter is idle (#323)

@hogend https://github.com/hogend Can you state what GPU, for the record?

— Reply to this email directly or view it on GitHub https://github.com/sddm/sddm/issues/323#issuecomment-136892096 . https://github.com/notifications/beacon/ANbIHaT4XwDSO6rvwN5zuj5FexV-Pl8eks5oti2_gaJpZM4DCEnK.gif

[jpsinthemix]

The problem is not with sddm, but with QtQuick2 (qtdeclarative); currently, has to do with how qtquick2 renders text; you can try:

echo 'QSG_DISTANCEFIELD_ANTIALIASING DEFAULT=subpixel-lowq' \

/etc/security/pam_env.conf

to force the use of a simply shader.

[xiangzhai]

So is it possible to develop traditional QWidget sddm greeter runtime swtich when target PC is very oooooold with limit RESOURCE?

[plfiorini]

I don't think QWidget is an option here, it's pointless for a login manager that wants to use recent stuff like QtQuick 2. Support for OpenGL 1.3 hardware might be achieved setting QT_XCB_FORCE_SOFTWARE_OPENGL=1 (see #575) for example.

Has anyone with the problem tested what happens with a simple theme and Text native rendering type (http://doc.qt.io/qt-5/qml-qtquick-text.html#renderType-prop) to see if that does something?

[realsobek]

I am using a virtualized Fedora 24 x86_64 with one CPU in VirtualBox and experience the problem on the login screen. The problem is present, if the cursor is blinking in a text input box.

'/etc/sddm.conf' uses by default the theme 01-breeze-fedora I installed other themes from the Fedora repository and they all have the same issue. As far as I can see Fedora llvmpipe. I am not sure, if this invalidates my test results.

In the file /etc/sddm.conf starting at line 25 I set the theme to:

[Theme]
Current=02-fedora

I edited the file: /usr/share/sddm/themes/02-fedora/Main.qml starting at line 186 (renderType line was added by me)

                    PasswordBox {
                        id: password
                        renderType: Text.NativeRendering

And restarted sddm: su -c 'systemctl restart sddm'

CPU usage drops from 10% to 0% according to top, but screen becomes completely white and unusable. Mouse cursor is not displayed. Removing the 'renderType' line and restarting SDDM make the screen usable again.

Shall I test something else?

[plfiorini]

Qt 5.8 will have the ability to pick a different QtQuick backend, including the new 2d backend that doesn't use OpenGL.

http://doc-snapshots.qt.io/qt5-dev/qtquick-visualcanvas-adaptations-software.html

In theory we can make a theme that doesn't use shaders (as far as I remember the themes that we provide do not depend on shaders) and enable the 2d backend making the greeter perform better on such hardware.

We can add a setting with the QtQuick backend that is used only when SDDM is built against Qt 5.8.

[xiangzhai]

Qt 5.8 will have the ability to pick a different QtQuick backend, including the new 2d backend that doesn't use OpenGL.

cool!

[sven76]

Is there any progress regarding this problem?

I'm running sddm on a Clevo W230SS notebook with an Intel HD 4600 card (8086:0416) and I'm still suffering this problem. The breeze theme produces an average cpu last of 30% on an Core-i7 (4712 mq). This runs low the battery in a short time and turns on the noisy fan.

In the meantime we are at QT-5.9. Thereby the choice of the different QtQuick backend should be available. If the problem couldn't be fixed in general, an option to disable the opengl backend in sddm.conf would help.

[jpsinthemix]

A Clevo W230SS notebook w/Intel HD 4600 should should have no problems with qtquick2; you most likely have a bug in the intel hd 4600 driver. Try installing the latest git/development driver from intel.

[bbkr]

I installed SDDM on Dell Mini 10v (Intel GMA945 + Atom 270) on bare Arch 32bit distro. Text entering was very laggy, after typing password character dot in text field appeared after 5-10 seconds.

Setting QSG_DISTANCEFIELD_ANTIALIASING reduced the lag to 0.1s. Not perfect but usable.

Thanks for hint!

BTW: Using theme https://store.kde.org/p/1186478/ further reduced input lag.

[jowagner]

Since there seems to be no volunteer to implement a more efficient way to let the cursor blink, how about implementing that the cursor stops blinking if there is no mouse or keyboard activity in the last 10 minutes? Optionally show a message "To save energy, the blinking of the cursor has been stopped. To re-activate the login screen, please press Esc or move the mouse.".

edit: typo

[chriswells0]

Just an FYI in case it helps someone else who comes across this issue:

I was having this problem on FreeBSD 12, which does not have /etc/security/pam_env.conf, so I tried setting the environment variable in /etc/profile. That did set the variable, but it did not resolve the issue.

However, in KDE's System Settings, changing Display and Monitor -> Compositor -> Rendering backend to OpenGL 2.0 (instead of 3.1) did resolve the issue for me.

[hcoin]

The problem still exists in Ubuntu disco. This problem makes sddm-greeter based distros unsuitable as typical qxl virtual machine guests as well as baremetal hosts on servers that are almost never 'about' graphics cards. The host has sddm-greeter at 10% cpu or so, plus each guest sucking 10% for nothing. This reality is entirely contrary to the 'lightweight' advertising these distros feature (some of them).
Solution: apt install tasksel apt update tasksel install ubuntu-mate-desktop <Choose lightdm, not sddm when asked> reboot.

[ShaheedHaque]

Using Ubuntu Disco, I found that QSG_DISTANCEFIELD_ANTIALIASING DEFAULT=subpixel-lowq had no effect, however, as per #575, this worked just fine:

echo 'QT_QUICK_BACKEND DEFAULT=software' >> /etc/security/pam_env.conf

[lbiiun8]

1. in KDE's System Settings, changing Display and Monitor -> Compositor -> Rendering backend to OpenGL 2.0 (instead of 3.1) not effect for me.
2. QSG_DISTANCEFIELD_ANTIALIASING DEFAULT=subpixel-lowq not effect too.

for: echo 'QT_QUICK_BACKEND DEFAULT=software' >> /etc/security/pam_env.conf It works. ths

[smoti17]

however, as per #575, this worked just fine:

echo 'QT_QUICK_BACKEND DEFAULT=software' >> /etc/security/pam_env.conf

Thank @ShaheedHaque you for this tip, it also solves a similar problem with kscreenlocker_greet which has been annoying me for some years. Before this fix, my "idle" Rasp Pi 4 was burning 2.3W just running sddm-greeter :-(, this is a significant issue on ARM systems where the GPU support is simply not (perhaps yet..) there.

[jessey-git]

Just chiming in that I also had to use the workaround suggested above. In my case I was using a linux vm in the cloud and using remote desktop for login. The particular vm type I'm using is cheap and gets throttled further according to CPU usage. Needless to say I was surprised after 2 days of running when I had run out of credits and was subsequently throttled hard :) Quickly spotted sddm "idling" at a full core of my 2 cpu vm... eventually landed here.