Bug 55998

Summary: Pretty huge slowdown in mesa 9.0
Product: Mesa Reporter: ValdikSS <iam>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED NOTOURBUG QA Contact:
Severity: major    
Priority: medium CC: andyrtr, arne.staecker, chadversary, dwyer, freedesktop, gbin, jlp.bugs, me, m, rohan, russianneuromancer, stefan.freyr, sundoulos2, weigert.stefan, wojtask9
Version: 9.0   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Bisect log (Kayden)

Description ValdikSS 2012-10-15 13:15:35 UTC
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.
Comment 1 Dami 2012-10-15 18:19:38 UTC
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.
Comment 2 Ben Gouhier 2012-10-15 21:20:01 UTC
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.
Comment 3 dwyer 2012-10-15 22:14:41 UTC
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)
Comment 4 Arthur Nascimento 2012-10-15 22:22:06 UTC
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?
Comment 5 dwyer 2012-10-15 22:47:30 UTC
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
Comment 6 ctarwater 2012-10-16 02:34:14 UTC
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.
Comment 7 Arthur Nascimento 2012-10-16 13:11:44 UTC
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
Comment 8 ValdikSS 2012-10-16 13:29:22 UTC
(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.
Comment 9 Arthur Nascimento 2012-10-16 13:43:38 UTC
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.
Comment 10 Stefán Freyr Stefánsson 2012-10-17 15:28:13 UTC
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
Comment 11 wojtek 2012-10-18 14:44:35 UTC
*** Bug 55856 has been marked as a duplicate of this bug. ***
Comment 12 dwyer 2012-10-20 02:59:45 UTC
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)
Comment 13 dwyer 2012-10-20 03:25:29 UTC
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.
Comment 14 weigert.stefan 2012-10-29 11:14:28 UTC
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
Comment 15 Fredrik Höglund 2012-10-29 16:22:46 UTC
Someone who is able to reproduce the problem is going to have to bisect it so we can know which commit caused the regression.
Comment 16 Kenneth Graunke 2012-10-29 18:40:10 UTC
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.
Comment 17 dwyer 2012-10-29 22:07:42 UTC
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?
Comment 18 wojtek 2012-10-30 00:09:59 UTC
(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.
Comment 19 Kenneth Graunke 2012-10-30 00:11:38 UTC
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...
Comment 20 wojtek 2012-10-30 00:26:07 UTC
> 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)
Comment 21 russianneuromancer 2012-10-30 00:45:11 UTC
wojtek, your issue with GLES is also reproducible on nouveau and radeon drivers. Your issue is not duplicate of this bug.
Comment 22 Fredrik Höglund 2012-10-30 03:25:18 UTC
(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.
Comment 23 Kenneth Graunke 2012-10-30 06:48:55 UTC
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.
Comment 24 Rune Petersen 2012-10-30 20:07:13 UTC
> 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...
Comment 25 Fredrik Höglund 2012-10-31 04:49:00 UTC
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.
Comment 26 Kenneth Graunke 2012-10-31 06:14:29 UTC
(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.
Comment 27 dwyer 2012-10-31 22:19:27 UTC
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.
Comment 28 ValdikSS 2012-10-31 22:31:45 UTC
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.
Comment 29 wojtek 2012-11-06 01:33:33 UTC
(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
Comment 30 Andrea Scarpino 2012-11-10 20:17:56 UTC
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.