Created attachment 113671 [details] MWE My Qt5 based application updates contents of a widget as the mouse moves over it. Unfortunately the drawing operation causes inexplicably high load and everything slows down to a crawl. During that time I observe Xorg fully loading one CPU core, the application itself does not seem to consume much CPU. My entire desktop is almost unusable until Xorg sorts itself out after a few seconds. As of now I found two possible workarounds: 1) Use Qt4 toolkit instead of Qt5 2) Set "Option" "NoAccel" to "true" in Xorg.conf I believe that this issue has to do with either GLAMOR or xf86-ati drivers because the application behaves normally on a machine with nVidia card or in Windows. I attached a small MWE which demonstrates the problem. Build the MWE with Qt5 toolkit, maximize the window and move mouse over the green area. Up-to-date Fedora 21 xorg-x11-server 1.16.3 mesa 10.4.3 xorg-x11-drv-ati 7.5.0
Oops, forgot to mention my GPU: Radeon 7730 LE
Can't seem to reproduce the problem with xserver 1.17, can you try that?
I got Fedora Rawhide to boot which currently ships Xorg 1.17.1 and Mesa 10.5. The problem is still there but it's nowhere near as bad as it is with stock Fedora 21. If I move the mouse fast enough over the green area for a long enough time, I will eventually see the crosshair being redrawn pretty slowly. The larger the green area, the worse the problem is. However, it takes considerably less time for the system to get back on its feet and it doesn't feel as slow while it's doing that so Xorg 1.17 definitely helps the situation. With Xorg 1.16 I see the overhead of "__memcpy_sse2_unaligned" skyrocketing over 20 % in "perf top" when the problem is triggered, with Xorg 1.17 it stays around 2 %. Qt4 builds work fine both under Xorg 1.16 and 1.17.
I checked the Xorg logs from the latest Fedora Rawhide and up-to-date Fedora 21 and it's possible that it all comes down to Color Tiling. Whereas xorg-server 1.17 reports Color Tiling as enabled it's disabled in 1.16. Is this supposed to happen? Is there any way I can force Color Tiling in 1.16 (Option "ColorTiling" "on" doesn't help)?
Is it better with current xf86-video-ati Git master and Option "ShadowPrimary"?
With the risk of possibly skewing the results I plugged a spare drive into my production box (that's where I'm experiencing the problem) and put a fresh Arch Linux installation on it. This testing installation is running kernel 3.19.3, GNOME 3.16, Xorg 1.17.1 and mesa 10.5.3. I tried get the system as close to my production F21 installation as possible. The problem seems to be gone here, either with or without bleeding edge Xorg DDX . On pre-alpha F22 I still observed some minor slowdowns which don't happen here. Enabling ShadowPrimary results in some image tearing and slightly lower system load, I suppose that's all down to the system not waiting for a pageflip. I'll check that the problem is indeed fixed once Fedora 22 hits final next month but it's looking good so far.
(In reply to madcatx from comment #6) > Enabling ShadowPrimary results in some image tearing and slightly lower system > load, I suppose that's all down to the system not waiting for a pageflip. With current Git, Option "TearFree" should eliminate tearing. The lower system load should be Option "ShadowPrimary" working as intended. :) > I'll check that the problem is indeed fixed once Fedora 22 hits final next > month but it's looking good so far. Sounds good, thanks.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/125.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.