I discovered this regression after upgrading to 4.9.5 from 4.9.3 in Kubuntu updates repository. I downgraded to 4.9.4 but the issue persists. I've just managed to narrow down what seems to be the issue to having the Scale method set to Accurate and with OpenGL 2 Shaders. If the scale method is anything else and OpenGL 2 shader active performance is fine. If scale method is Accurate and OpenGL 2 shaders is disabled performance is still fine. It is only when the two are combined that many effects become extremely slow and difficult to use. I've noticed if I have 2 windows open on two separate screens I can hover my mouse between both and get the expected smooth highlighting effects. Any more windows and its back to choppiness. I've also noticed I can always move back to the active window and it will highlight smoothly. It is any other window that will be very choppy. Affected effects are: * Present windows. The effect initiates as smoothly as always but as soon as I hover the mouse over another window (and it highlights and the close cross appears) the transition is very very slow and choppy. I have to keep my mouse still over the window until it takes focus. Otherwise everything feels jerky. I've tried various combinations of present window settings but the result is the same. * Desktop grid is also much slower and seem to jerk as I move mouse over other desktops and does not smoothly scale into chosen desktop. * Tab box switcher is very slow to activate but once activated will transition between windows just fine. Note this has been tested on an Intel HD4000 GPU (Core i7-3520M) using both Mesa 9 stable and git Mesa from about a week ago. I have another system with an Nvidia 460 GTX GPU using the binary blob that does not have this issue. If I knew how to safely downgrade to 4.9.2 which is in the Kubuntu repository I would double check that the problem was not present but I don't know how to do that (I used ppa-purge to automate 4.9.5 -> 4.9.4). I'm quite sure I always used scale method accurate previously though. Reproducible: Always Steps to Reproduce: 1. Go to desktop effects Advance tab and set scale method to Accurate and enable OpenGL 2 shaders. 2. Load multiple windows (at least 3) 3. Activate present windows. 4. Hover mouse over any other window except active window and note the slow performance. Actual Results: Effects are slow and choppy. Expected Results: Smooth effects. $ lspci 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4) 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 02:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 07) 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)
There is no relevant change between 4.9.3 and 4.9.4 in that area. Are you sure that no other component change, e.g. a driver update? And that you did not maybe had different settings?
I considered the drivers as well as I was running tweaked versions from https://launchpad.net/~oibaf/+archive/graphics-drivers. But I reverted these to the stable release. I'll try Intel's SNA acceleration when I get the chance to see if that has an affect. I'll also see about testing out a live usb of Kubuntu to verify it is a regression.
You probably updated mesa as well, yesno? -> output of "glxinfo -l" Also please post/attach "qdbus org.kde.kwin /KWin supportInformation"
Created attachment 76597 [details] glxinfo -l
Created attachment 76598 [details] Kwin Support information @Thomas Lübking, attached per your request.
mesa 9.1 devel. Sorry that means a regression in the driver. Seems to be a more common problem at the moment - e.g. bug #313599
Ah man you're right. Should have verified that the purge had worked correctly. Sorry. When I've got that sorted I'll report back on whether it resolved the issue or not. Thanks for the exceptionally fast replies.
I've downgraded Mesa. Then did 'kwin --replace' which I believe should cause the updated Mesa library to be used and performance of the effects seems back to normal with OpenGL 2 shaders and scale method Accurate. Could anyone suggest to me where and what I should be reporting to upstream?
http://www.mesa3d.org/bugs.html
Sorry for reporting this so late. I only just got round to installing the latest Mesa again to test if the problem still exists and it does so I've created an upstream bug report at: https://bugs.freedesktop.org/show_bug.cgi?id=61554
Created attachment 77616 [details] Patch I used to add a debug message in lanczosfilter.cpp
Reviving this bug report as per the following thread: http://lists.kde.org/?l=kwin&m=136195401110702&w=2 After upgrading mesa from 9.0.2 to 9.1, some task switcher layouts became really slow: the Grid layout takes 3-4 seconds to show the thumbnails, while the Thumbnails layout takes 1-2 seconds. The other layouts (including Cover Switch and Flip Switch) are fast as usual. I am on Intel HD4000 graphics (Ivybridge), Linux kernel both 3.7.9 and 3.8, and KDE 4.10. To make the Grid and Thumbnails layout useful, I have to set the Scale method to Smooth instead of Accurate or disable OpenGL 2 shaders. While testing kwin_gles, I discovered it is completely unusable with mesa 9.1 (see the attached screenshot), while it works fine with mesa 9.0.2. I am attaching some logs, obtained with mesa 9.1 and 9.0.2
Created attachment 77617 [details] Output of glxinfo -l with mesa 9.0.2
Created attachment 77618 [details] Output of kwin --replace with mesa 9.0.2
Created attachment 77619 [details] Output of kwin_gles --replace with mesa 9.0.2
Created attachment 77620 [details] Debug messages after switching tasks with grid layout Should show that the lanczos filter is used
Created attachment 77621 [details] Output of glxinfo -l with mesa 9.1
Created attachment 77622 [details] Output of kwin --replace with mesa 9.1
Created attachment 77623 [details] Output of kwin_gles --replace with mesa 9.1
Created attachment 77624 [details] Debug messages after switching tasks with grid layout Should show that the lanczos filter is used
Created attachment 77625 [details] Screen after kwin_gles --replace with mesa 9.1
Just an FYI: I never got that kind of screen corruption when I tried KWin gles. It did seem to perform a bit better when triggering the scale effects but not much so. I figured that was down to the gles version performing a little faster but still hitting the same bug. I did not test gles for all that long though. If wanted I could run the same tests Stefano has done at some point but I can't do that right now.
random observation: the number of visuals and framebuffer configs went down by more than half in the 9.1 output. This could indicate that a suboptimal framebuffer config gets chosen.
(In reply to comment #23) > random observation: the number of visuals and framebuffer configs went down > by more than half in the 9.1 output. This could indicate that a suboptimal > framebuffer config gets chosen. I did also notice this thing. Is it something we should inform mesa devs about?
Picked buffers seem equal, though. 0x0ef 24 dc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None 0x0bd 24 dc 0 32 0 r y . 8 8 8 8 . . 0 0 0 0 0 0 0 0 0 None (while "ef" used to have a skiped sibling "ee")
*** Bug 315879 has been marked as a duplicate of this bug. ***
Just the obvious comment: it would be awesome if someone would bisect mesa to figure out which commit introduced the regression. That would tell us whether it's in Mesa or in KWin to fix. Short term solution we can do in KWin is to block Lanczos for IvyBridge and Mesa 9.1
Workaround: https://git.reviewboard.kde.org/r/109200/ It would be great if someone could test it, I'm lacking the hardware so I don't know whether it works :-)
@Martin Gräßlin I've just built a local copy of Mesa from git. Ran my current distro package Kwin 4.10 and still got the issue (just to verify). I then grabbed the deb-source and applied your patch. Built kwin and ran ./kwin --replace in the local build and its working just fine. Note that I built and installed Mesa and drm locally and ran in the terminal: $ export LD_LIBRARY_PATH=/home/magicmyth/Work/src/mesa/build/prefix/lib $ export DRI_DRIVER_PATH=/home/magicmyth/Work/src/mesa/build/prefix/lib/dri $ ./kwin --replace This is what kwin outputted in the terminal: ============ CONSOLE OUPUT ============== OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL version string: 3.0 Mesa 9.2-devel (git-c6ae108) OpenGL shading language version string: 1.30 Driver: Intel GPU class: IvyBridge OpenGL version: 3.0 GLSL version: 1.30 Mesa version: 9.2 X server version: 1.13 Linux kernel version: 3.5 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no ==================================== So it looks like I am running the right (or bad) Mesa version. And that the patch does indeed work around the problem. I will try to bisect the Mesa commit that causes this issue at a later date but probably won't have time to do that for a couple of days. A bit of topic. I tried to run with LIBGL_DRIVERS_PATH set to my local build like so: $ export LIBGL_DRIVERS_PATH=/home/magicmyth/Work/src/mesa/build/prefix/lib But all apps fail with: $ libGL error: failed to load driver: i965 Anyone know what that should be set to so that I used my local build of the dri drivers? I tried pointing it to the lib/dri folder as well.
My battle against git bisect is finally over. And the winner is: a64c1eb9b110f29b8abf803a8256306702629bdc is the first bad commit commit a64c1eb9b110f29b8abf803a8256306702629bdc Author: Eric Anholt <eric@anholt.net> Date: Thu Nov 8 16:06:24 2012 -0800 i965/fs: Add support for uniform array access with a variable index. Serious Sam 3 had a shader hitting this path, but it's used rarely so it didn't show a significant performance difference (n=7). It does reduce compile time massively, though -- one shader goes from 14s compile time and 11723 instructions generated to .44s and 499 instructions. Note that some shaders lose 16-wide mode because we don't support 16-wide and pull constants at the moment (generally, things looping over a few-element array where the loop isn't getting unrolled). Given that those shaders are being generated with 15-20% fewer instructions, it probably outweighs the loss of 16-wide. http://cgit.freedesktop.org/mesa/mesa/commit/?h=9.1&id=a64c1eb9b110f29b8abf803a8256306702629bdc Please let me know if you think it is a mesa bug, in which case I will post the outcome of git bisect to the bug report opened by Adam.
thanks a lot for bisecting. I think we now have to go to Mesa devs with the shader and the commit and see what they can tell us
Just let me know if you want me to do anything (e.g., provide git bisect log, report to mesa devs, etc.)
Git commit 78a9ca708a5764169c456b9cff2268327c09041f by Martin Gräßlin. Committed on 28/02/2013 at 08:49. Pushed by graesslin into branch 'KDE/4.10'. Disable Lanczos for IvyBridge with Mesa 9.1 I don't like to do it, but it's better than users getting a bad performance experience. The change should be reverted once the issue is identified and fixed. REVIEW: 109200 M +3 -0 kwin/lanczosfilter.cpp http://commits.kde.org/kde-workspace/78a9ca708a5764169c456b9cff2268327c09041f
(In reply to comment #32) > Just let me know if you want me to do anything (e.g., provide git bisect > log, report to mesa devs, etc.) I have just updated the bug on freedesktop: https://bugs.freedesktop.org/show_bug.cgi?id=61554
*** Bug 317427 has been marked as a duplicate of this bug. ***
This is not fully worked around. SandyBridge is also affected by this problem (bug 317427).
Upstream claims that's fixed with 62501c3af85089b423218a41a2e2433ac849c2d3 Applied the patch and here it is still visible. In the meantime I updated my laptop (Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz) and there it's the same; patched mesa does not provide smooth scaling. So probably there is still another issue around?
> Upstream claims that's fixed with 62501c3af85089b423218a41a2e2433ac849c2d3 > Applied the patch and here it is still visible. In the meantime I updated my > laptop (Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz) and there it's the same; > patched mesa does not provide smooth scaling. So probably there is still > another issue around? Then please report upstream. Here this info doesn't help
> Upstream claims that's fixed with 62501c3af85089b423218a41a2e2433ac849c2d3 No, they say that it is fixed in the patch series that ends with that commit. One other SandyBridge user confirms that this fixes it. https://bugs.freedesktop.org/show_bug.cgi?id=61554#c16
Git commit 45900e7e1ad1c1fbd997b7fb52117a4d9edc5969 by Martin Gräßlin. Committed on 21/05/2013 at 08:15. Pushed by graesslin into branch 'master'. Enable Lanczos for IvyBridge and Mesa 9.2 again Performance regression is fixed in Mesa 9.2. See Bug report https://bugs.freedesktop.org/show_bug.cgi?id=61554 REVIEW: 110569 M +1 -1 kwin/lanczosfilter.cpp http://commits.kde.org/kde-workspace/45900e7e1ad1c1fbd997b7fb52117a4d9edc5969
@Martin, seems the fix ended up in Mesa 9.1.3: Bug 61554 - [ivb] Mesa 9.1 performance regression on KWin's Lanczos shader can it be also enabled in 4.10 branch for >= 9.1.3?
On Saturday 25 May 2013 11:29:49 you wrote: > @Martin, seems the fix ended up in Mesa 9.1.3: > Bug 61554 - [ivb] Mesa 9.1 performance regression on KWin's Lanczos shader > can it be also enabled in 4.10 branch for >= 9.1.3? My understanding was that they did not want to backport as it was a too large change. I'm unsure about adding this to 4.10 again as we would need to check for all three version numbers and that's something we have not done yet. We only check major versions. Also one can enforce the Lanczos filter using: KWIN_FORCE_LANCZOS=1 kwin --replace &