Hello! I'm using Intel HD3000, KDE 4.9.2, Mesa 9.0 and it's much slower than with mesa 8.0.4 in KWin with OpenGL backend and with VSync enabled, and you can see tearing. Not sure if this mesa or kwin bug.
I'm getting this as well. Arch Linux Intel HD Graphics 3000 KDE 4.9.2 MESA 9.0 The tearing seems to occur only in one area, about 1/5th of the way down the screen. It is as if the first 5th of the screen is updating slower. Downgrading Intel-DRI and libgl to 8.0.4 fixed the issue. Tried TearFree option in Xorg.conf and that gets rid of the tearing but makes the graphics unusably slow using KWin/OpenGL.
I am getting this too, both with intel Sandy Bridge and radeon Xpress200m, with free drivers. They both use mesa 9.0 and kde 4.9.2, and the tearing happens in the top and bottom 1/5th parts of the screen. Going back to 8.0.4 solves the issue.
Same problem with i7-3520M HD4000 graphics: Thinkpad X230 Archlinux x86_64 Intel HD4000 KDE 4.9.2 _OpenGL MESA 9.0 Kernels tried: 3.5.6-1-grsec 3.6.1-2-grsec And Arch default kernel 3.5.6-1-ARCH Same tearing about 1/5th of the way down the screen, Arrifacts on screen, and slow. At first I did just try downgrading xf86-video-intel, but still broken. Then I whent fullboar and downgraded all of it to fix it. [2012-10-14 16:25] upgraded libglapi (8.0.4-3 -> 8.0.4-3) [2012-10-14 16:25] upgraded libgl (9.0-1 -> 8.0.4-3) [2012-10-14 16:25] upgraded mesa (9.0-1 -> 8.0.4-3) [2012-10-14 16:25] upgraded freeglut (2.8.0-2 -> 2.8.0-1) [2012-10-14 16:25] upgraded ftgl (2.1.3rc5-4 -> 2.1.3rc5-3) [2012-10-14 16:25] upgraded gegl (0.2.0-4 -> 0.2.0-3) [2012-10-14 16:25] upgraded glew (1.8.0-2 -> 1.8.0-1) [2012-10-14 16:25] upgraded gtkglext (1.2.0-8 -> 1.2.0-7) [2012-10-14 16:25] upgraded jasper (1.900.1-8 -> 1.900.1-7) [2012-10-14 16:25] upgraded intel-dri (9.0-1 -> 8.0.4-3) [2012-10-14 16:25] upgraded libgles (9.0-1 -> 8.0.4-3) [2012-10-14 16:25] upgraded libgbm (9.0-1 -> 8.0.4-3) [2012-10-14 16:25] upgraded libegl (9.0-1 -> 8.0.4-3) [2012-10-14 16:25] upgraded lib32-libglapi (9.0-1 -> 8.0.4-4) [2012-10-14 16:25] upgraded lib32-libgl (9.0-1 -> 8.0.4-4) [2012-10-14 16:25] upgraded lib32-intel-dri (9.0-1 -> 8.0.4-4) [2012-10-14 16:25] upgraded xf86-input-evdev (2.7.3-2 -> 2.7.3-1) [2012-10-14 16:25] upgraded xf86-input-synaptics (1.6.2-2 -> 1.6.2-1) [2012-10-14 16:25] upgraded xf86-video-intel (2.20.9-2 -> 2.20.9-1) [2012-10-14 16:25] upgraded xorg-server-common (1.13.0-2 -> 1.12.4-1) [2012-10-14 16:25] upgraded xorg-server (1.13.0-2 -> 1.12.4-1)
I got similar specs: Intel SandyBridge HD 3000, KDE 4.9.2, Mesa 9.0, KWin on OpenGL with VSync, in Exherbo Linux. But I _do not_ see the problem. I suppose whatever is different between our systems must be the source of the problem. What else can we compare?
Hum, well I am using "uxa". sna was crashing for me on the original install about a month or so ago. I'll try sna again.. Section "Device" Identifier "Intel Graphics" Driver "intel" #Option "AccelMethod" "sna" Option "AccelMethod" "uxa" EndSection
I'm experiencing the same issue here. Here's my specs: Up to date Arch Linux Asus U43F-BBA6 laptop Intel HD Graphics / 4300 KDE 4.9.2 Mesa 9.0 Intel SNA Changing to Xrender from OpenGL was the only way I could fix the issue.
I'm on SNA as well. How about comparing the ./configure options? For Mesa 9.0: ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --docdir=/usr/share/doc/mesa-9.0 --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=/usr/lib64 --with-egl-platforms=x11,drm --enable-dri --enable-glx --enable-gles1 --enable-gles2 --enable-glx-tls --enable-egl --disable-va --enable-64-bit --enable-gallium-llvm --enable-texture-float --disable-vdpau --enable-xorg --disable-xvmc --disable-gallium-g3dvl --with-dri-drivers=swrast,i915,i965,intel --with-gallium-drivers=i915 --enable-gallium-egl --enable-openvg --enable-gbm --enable-shared-glapi --disable-opencl --enable-gallium-gbm --disable-gallium-g3dvl --with-dri-drivers=swrast,i915,i965,intel --with-gallium-drivers=i915 --enable-gallium-egl --enable-openvg --enable-gbm --enable-shared-glapi --disable-opencl --enable-gallium-gbm For xf86-video-intel 2.20.10: ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --docdir=/usr/share/doc/xf86-video-intel-2.20.10 --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=/usr/lib64 --enable-dri --enable-xvmc --disable-dga --disable-xaa --enable-udev --disable-uxa --enable-sna --disable-debug
(In reply to comment #7) COMMONOPTS="--prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \ --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \ --enable-gallium-llvm \ --enable-egl \ --enable-gallium-egl \ --with-egl-platforms=x11,drm \ --enable-shared-glapi \ --enable-gbm \ --enable-glx-tls \ --enable-dri \ --enable-glx \ --enable-osmesa \ --enable-gles1 \ --enable-gles2 \ --enable-texture-float \ --enable-xa \ --enable-vdpau " This bug doesn't depend on xf86-video-intel.
Perhaps, but SNA was mentioned and I only found it on xf86-video-intel. I must say I do experience problems with this setup - just not the 1/5th screen tearing or the slowdown. One of the problems - random X freezes and I have to SysReq my way out of X - disappears when I disable vdpau and xvmc on Mesa (xvmc is still enabled in xf86-video-intel, though). And the other is glitches after suspend/wakeup, but similar glitches happen to the audio, so it probably has nothing to do with the subject.
I also have this problem on Kubuntu 12.10. I filed a bug on launchpad which just got connected with this bug. https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1061073
*** Bug 55856 has been marked as a duplicate of this bug. ***
Okay, I just did a full upgrade to my Arch Linux x86_64 Kernel 3.6.2-grsec Intel HD4000 KDE4 with OpenGL (no problem with XRender) System. horable Artifacts, Tarring, and slow. Then I down graded only these three packages. Now I still have Tarring. However, it fixed the Artifacts problem and the desktop seems fast again. libglapi (9.0-1 -> 8.0.4-3) libgl (9.0-1 -> 8.0.4-3) intel-dri (9.0-1 -> 8.0.4-3)
I tried downgrading to: mesa-8.0.4-3 ftgl-2.1.3rc5-3 glew-1.8.0-1 gtkglext-1.2.0-7 jasper-1.900.1-7 And removeing the new package glu-9.0.0-1 However, this seemed to have not effect. I have upgraded back to mesa-9 and stuff, becuause the downgrade did not fix the Tarring. One other thing that has changed after the downgrade of: libglapi (9.0-1 -> 8.0.4-3) libgl (9.0-1 -> 8.0.4-3) intel-dri (9.0-1 -> 8.0.4-3) Is that now the Tarring line is not staying at 1/5th the way down the screen. Instead now the Tarring line slowly starts at the bottom of the screen and moves to the top, then starts at the bottom again.
hi, what is the state on this bug? is it worth trying to downgrade mesa or will a fix be released soon? is it mesa's fault at all? cheers
Someone who is able to reproduce the problem is going to have to bisect it so we can know which commit caused the regression.
Unfortunately, I can't seem to reproduce this: I also have KDE 4.9.2 and Mesa 9.0, but it appears to work fine for me.
I currently have a fully upto date Arch Linux x86_64 system with Intel HD4000 I am still at the state where I have to downgrade libglapi (9.0-1 -> 8.0.4-3) libgl (9.0-1 -> 8.0.4-3) intel-dri (9.0-1 -> 8.0.4-3) I leave mesa at 9.0.1. Downgrading Mesa dose not seem to help anything. However, when I upgrade these three packages I get artifacts. I will not have time until Friday to work on the problem. What are the steps you would like me to take to bisect the problem?
(In reply to comment #16) > Unfortunately, I can't seem to reproduce this: I also have KDE 4.9.2 and > Mesa 9.0, but it appears to work fine for me. My knowledge about mesa and opengl is very limited so sorry about my terminology. To reproduce this bug you must use kwin_gles (http://blog.martin-graesslin.com/blog/2011/07/running-kwin-with-opengl-es-2-0/). Using gentoo try set USE flags "gles -opengl" at kwin package. With kwin default (i think it is call backend) opengl everything is ok. Like I said in https://bugs.freedesktop.org/show_bug.cgi?id=55856 this not happen in mesa-9.0_pre20120918. Until friday I'm not able to bisect mesa to find a commit that cause regression. If nobody bisect mesa I will try.
Created attachment 69265 [details] Bisect log (Kayden) I managed to reproduce this after all. Steps to reproduce: 1. Enable KWin's "Show FPS" counter plugin. 2. Configure the "Present Windows" effect to one of the screen corners. 3. Mash that repeatedly and watch the FPS counter. On HD 4000, a good version of Mesa results in perhaps ~55-60 FPS. Bad Mesa can be as low as 17 FPS, often mid-30s. I also went ahead and bisected it (the log is attached). e943e5c291c5f4c017f9f5a483f1940313333fc3 is the first bad commit commit e943e5c291c5f4c017f9f5a483f1940313333fc3 Author: Chad Versace <chad.versace@linux.intel.com> Date: Thu Aug 2 17:13:17 2012 -0700 intel: Advertise multisample DRI2 configs on gen >= 6 This turns on window system MSAA. So in other words, it looks like KDE is using multisampling now, whereas it didn't before. Our implementation of that may not be optimal, and may have bugs, but it will always be far slower than single sampling. My next question would be: how can one disable the use of MSAA in KWin or Plasma? I don't see an option for that, but I would be really surprised if there wasn't one...
> intel: Advertise multisample DRI2 configs on gen >= 6 i can reproduce this bug on Gen4 (Lenovo T61). >Author: Chad Versace <chad.versace@linux.intel.com> >Date: Thu Aug 2 17:13:17 2012 -0700 strange because on my system with mesa-9.0_pre20120918 everything is ok (3 times downgrade mesa to be sure on my system)
wojtek, your issue with GLES is also reproducible on nouveau and radeon drivers. Your issue is not duplicate of this bug.
(In reply to comment #19) > e943e5c291c5f4c017f9f5a483f1940313333fc3 is the first bad commit > commit e943e5c291c5f4c017f9f5a483f1940313333fc3 > Author: Chad Versace <chad.versace@linux.intel.com> > Date: Thu Aug 2 17:13:17 2012 -0700 > > intel: Advertise multisample DRI2 configs on gen >= 6 > > This turns on window system MSAA. > > So in other words, it looks like KDE is using multisampling now, whereas it > didn't before. Our implementation of that may not be optimal, and may have > bugs, but it will always be far slower than single sampling. > > My next question would be: how can one disable the use of MSAA in KWin or > Plasma? I don't see an option for that, but I would be really surprised if > there wasn't one... The algorithm that chooses the FBConfig doesn't check the values of GLX_SAMPLES and GLX_SAMPLE_BUFFERS, so I guess it ends up picking an MSAA config purely by accident. That's something we'll have to fix in KWin. But unfortunately that also means that there is no way to enable or disable the use of MSAA right now.
Ouch. Well...in that case, I'm not sure what to do on the Mesa side...perhaps a point release of KWin could fix this? For what it's worth, KWin from git master has the slowdown with the GLX backend, but appears to work well with the EGL backend. I imagine that's because it uses eglChooseConfig, and doesn't request any samples, so Mesa gives it a proper non-MSAA config. It's just with GLX, where KWin rolls its own algorithm, that there's a problem.
> The algorithm that chooses the FBConfig doesn't check the values of > GLX_SAMPLES and GLX_SAMPLE_BUFFERS, so I guess it ends up picking an MSAA > config purely by accident. That's something we'll have to fix in KWin. > > But unfortunately that also means that there is no way to enable or disable > the use of MSAA right now. Usually implementations choose the first config that matches its main criteria (just alpha, red, green, and blue for basic apps) Are the MSAA configs at the top of the list? The spec. has ordering rules for each attribute and the order for EGL_SAMPLES is accending...
I've pushed a patch to KWin that should fix the problem. The patch is in both master and the 4.9 branch, so you should see it in 4.9.3. That release will be tagged on Thursday. @Rune: The GLX backend in KWin uses glXGetFBConfigs(), so the ordering rules in the spec don't apply here. I've thought about rewriting that code to use glXChooseFBConfig(), but I'm reluctant to touch working code without a good reason. This bug might be enough of a reason to do that though.
(In reply to comment #25) > I've pushed a patch to KWin that should fix the problem. The patch is in > both master and the 4.9 branch, so you should see it in 4.9.3. That release > will be tagged on Thursday. Thanks Fredrik! Based on that, I'm closing this as RESOLVED/NOTOURBUG. > @Rune: The GLX backend in KWin uses glXGetFBConfigs(), so the ordering rules > in the spec don't apply here. I've thought about rewriting that code to use > glXChooseFBConfig(), but I'm reluctant to touch working code without a good > reason. This bug might be enough of a reason to do that though. @Rune: Feel free to double check by running glxinfo, but I believe the ordering is correct: multisample configs are always sorted later, as required. Using glXChooseFBConfig() does seem like a good idea...could guard against future problems (though I don't know what), and should simplify the code a fair bit. Also, KWin's EGL backend uses eglChooseConfig() and it never had this problem. That would also make the GLX and EGL backends more similar. Thanks again.
Okay, Arch Linux has now put out... kdebase-workspace 4.9.2-6 Which I guess has this patch applied. My system is now all up-to-date and there are no more Artifacts or slow down. However, the Tarring line is still there.
For me, this fixes slowdown which I wrote in the first message. There is 2 other bugs: screen corruption with gles and incorrect screen repainting with gl. And I don't know if it's MESA or KDE bugs.
(In reply to comment #21) > wojtek, your issue with GLES is also reproducible on nouveau and radeon > drivers. Your issue is not duplicate of this bug. git bisect bad e1cb50b15dbb75d1ba0fe184d05be7d302b058ee is the first bad commit commit e1cb50b15dbb75d1ba0fe184d05be7d302b058ee Author: Robert Bragg <robert@linux.intel.com> Date: Tue Sep 18 16:10:03 2012 +0100 SwapBuffersRegionNOK: invert rectangles on y axis The EGL_NOK_swap_region2 spec states that the rectangles are specified with a bottom-left origin within a surface coordinate space also with a bottom left origin, so this patch ensures the rectangles are flipped before passing them on to dri2_copy_region. Fixes piglit's egl-nok-swap-region test. Tested-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 0a523a8820e8a2549ac1c7887eb1892b228af44b) this commit introduced regression on my system (kwin_gles) I'll reopen https://bugs.freedesktop.org/show_bug.cgi?id=55856
Thanks Robert! Can you backport this so it gets included in the next 9.0.1 release?
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.