Note: This looks like issue 311799, but it actually only started appearing on Plasma 5 for me and has some different characteristics, therefore I'm opening a new bug report. The progress indicator/spinner which appears in the panel when opening applications or copying files spins as fast as it can and thus causes 100% CPU usage on one core by process plasmashell, but only on nvidia Optimus systems. This may be caused by the nvidia GPU not really explicitly being limited by a refresh rate from a monitor, therefore making the spinner run in a busy loop. If the Intel GPU is used (i.e. xorg.conf changed to use the intel driver instead of modesetting, and the system restarted), the spinner works as expected. My hypothesis on how this happens is that some function to get a refresh rate returns 0.0, something then calculates the swap interval by dividing 1000.0 by 0.0 which thanks to IEEE floats doesn't result in an exception but Infinity (because mathematical correctness is more important than usability), and then something goes if(time_elapsed - swap_interval <= 0) { sleep(something);} which is always true thanks to -infinity being <= 0. Though, quickly testing what a framework such as glfw says about my primary monitor's refresh rate, it actually returns non-zero values, so the above hypothesis may very well be wrong. Reproducible: Always Steps to Reproduce: 1. Get an nvidia optimus laptop 2. Follow these steps: https://wiki.archlinux.org/index.php/NVIDIA_Optimus#Using_nvidia 3. Copy a large file and watch the spinner as well as plasmashell's CPU usage Actual Results: The spinner spins really fast, causing massive CPU usage Expected Results: The spinner updates at a rate which resembles the actual refresh rate. KWIN_TRIPLE_BUFFER="1"
Thanks for the report and the analysis. Unfortunately I'm not sure if we actually have any control over at what speed the spinner updates. We use QtQuick's Animator[1] to perform the animation. More specifically, the RotationAnimator[2]. And that's performed directly on GPU. It may very well be that this is either a Qt (QtQuick) bug or the nvidia driver bug; Plasma itself has just a pretty high-level usage of it. What I would suggest is try to create a minimal test example using the RotationAnimator on a simple image or Rectangle and test that. If that still goes berserk on your CPU, then it's QtQuick's bug and/or driver's. If not, then we may have something on our side indeed. [1] http://doc.qt.io/qt-5/qml-qtquick-animator.html [2] http://doc.qt.io/qt-5/qml-qtquick-rotationanimator.html
Thanks for the quick reply. I'll try to create a minimal testcase and report back with my findings. As an additional sidenote, if this truly is an nvidia driver bug, then it may be resolved if they finally implement PRIME buffer fencing, since the nvidia GPU will then wait for the Intel GPU to finish its read before writing to the buffer again.[1] [1] https://devtalk.nvidia.com/default/topic/775691/linux/vsync-issue-nvidia-prime-ux32vd-with-gt620-m-/post/4430873/#4430873
I have created a minimal test case which exhibits the same behaviour: the rectangle spins insanely fast, and the CPU usage spikes. Thus we can conclude that this is a bug in QtQuick or in the nvidia driver. Link to test case: https://github.com/CounterPillow/spinnertest
Thanks for your effort! I think it's best if you head over to https://bugreports.qt.io/ and file a bug against QtQuick there.
Reported upstream here: https://bugreports.qt.io/browse/QTBUG-45959
Here's a manual workaround until upstream Qt either implements automatic detection of this + a workaround or upstream nvidia actually gets off their asses: Create a script with "export QSG_RENDER_LOOP=basic" and add it as auto-start before the KDE login. If somebody manages to do accurate detection of optimus systems (perhaps using xrandr --listproviders?) distributions could even include a small autostart script to do this for users.
I have the same issue with an Intel card. I highly doubt it is an upstream problem.
> I highly doubt it is an upstream problem. The animation is performed by Qt/QtQuick. Qt is upstream.
*** Bug 351888 has been marked as a duplicate of this bug. ***
Apparently NVIDIA is coming with an update, Qt probably won't provide a work-around. As far as the problem is caused by Plasma and Frameworks itself, that should be close to being fixed - see https://bugs.kde.org/show_bug.cgi?id=336274
I'm encountering the same 100% CPU on an Intel Card, so it has nothing to do with nvidia. The mentioned spinnertest example program uses here just 3% CPU, so it seems this is neither an nvidia nor a Qt bug. Side question: if the spinner is calculated on the GPU, then why is the CPU using 100% ? Should I create a new bug report or shall we reopen this one ?