Desktop effects are slow and desktop corruption using mesa 9

(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
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 <email address hidden>
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 <email address hidden>
>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 <email address hidden>
> 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.

Just to be clear. I was talking about the non-gles version of Kwin when testing. Don't know if a bug report should be created specifically for the MSAA bug which seems to be what caused the screen corruption as well as slowdown in kwin standard OpenGL.

The slowdown gone, but I have screen freeze issue now. Like, the screen is not always updated and if you click somewhere you think nothing happened but if you minimize and restore window, you see that click worked.

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.

*** Bug 309510 has been marked as a duplicate of this bug. ***

*** Bug 308369 has been marked as a duplicate of this bug. ***

(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 <email address hidden>
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 <email address hidden>
    (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

bug for gles 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?

The slowdown is gone for me except in fullscreen HD videos (either VLC or flash - 720p+). I am quite sure this is a KWin bug because I tried downgrading to Mesa 8.0.4 (which was working fine before) and I experienced the same issues. So it is something in the 4.9.2 -> 4.9.3 transition (perhaps even the above patch).

I also noticed that low resolution videos (480p) play smoothly, as well as the HD videos but only when not viewed fullscreen.

Mesa: 9.0
KDE: 4.9.3
Linux: 3.6.6
Intel Driver: 2.20.12
Intel HD Graphics 4000

(In reply to comment #37)

> I also noticed that low resolution videos (480p) play smoothly, as well as
> the HD videos but only when not viewed fullscreen.

"kcmshell4 kwincompositing", last tab. is "suspend compositing for fullscreen windows" checked? Do they play faster if you suspend compositing altogether?

(In reply to comment #38)
> (In reply to comment #37)
>
> > I also noticed that low resolution videos (480p) play smoothly, as well as
> > the HD videos but only when not viewed fullscreen.
>
> "kcmshell4 kwincompositing", last tab. is "suspend compositing for
> fullscreen windows" checked? Do they play faster if you suspend compositing
> altogether?

It is not checked, with KDE 4.9.2 + Mesa 8.0.4 it worked fine unchecked.

Checking it and/or disabling effects altogether caused VLC to play smoothly fullscreen.

Flash remained unaffected either way (it doesn't simply slow down, it fails to expand the video fullscreen and freezes the video).

Iff at all, rather
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=9364f5a7579567f5ebcf537eccf6147416e0e7e0
or maybe
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=55a2f19c8a41d9b3d13d69d7769999daf5730414

- Can you check reverting the commits?

- Sure the intel driver (xf86-video-intel) / flash / vlc/libav didn't change between "works" and "works not"?

This:
"Flash remained unaffected either way (it doesn't simply slow down, it fails to expand the video fullscreen and freezes the video)."
Smells suspicious, since with suspended compositing, kwin is actually out of game here.

- I tried reverting the commits each alone and together and the result is that the first commit introduced the VLC slowdown.

- Checking my logs, there was a google-chrome update along with KDE 4.9.3. It could be that the flash issues are totally unrelated (I am using the built-in flash player).

Just for reference:
Reverting commit 1+2: VLC is OK, Flash freezes
Reverting commit 1: VLC is OK, Flash freezes
Reverting commit 2: VLC is slow, Flash freezes

Suspending the effects for fullscreen windows stops the VLC slowdown but when another window pops up (e.g. KMix's volume indicator) it becomes sluggish again. Suspending the effects altogether produces no slowdown at all.

Yep, I can confirm that the flash issue is unrelated. External flash (11.2) works fine, please ignore the issue. Chrome 23 ships flash 11.5.

kwriteconfig --file kwinrc --group Compositing -- key GLStrictBinding true
qdbus org.kde.kwin /KWin reconfigure
then toggle compositing off / on (shift+alt+f12)

Completely suspend compositing in that case will however likely still get you the best overall performance.

@Fredrik:
the commit is not commented - what was the reason behind this (possibly related to a special driver version?)

Just updated xf86-video-intel to 2.20.13 and get lags with mplayer -vo gl fullscreen without suspending compositing for fullscreen windows. It happens only with SNA. Everything is fine with UXA.

(In reply to comment #43)
> @Fredrik:
> the commit is not commented - what was the reason behind this (possibly
> related to a special driver version?)

With DRI2 drivers there is no need to rebind the window pixmap to the texture every time the window is damaged. The texture and the pixmap reference the same memory buffer.

This commit has no effect on the GLES backend however, since it always enables loose binding unconditionally.

@Konstantinos: are you actually running kwin_gles?

No, standard OpenGL.

The original bug is fixed with commit in comment #29, thus closing.

Regarding the video slowdown / other issues regarding non-strict binding, please check whether this is still an issue (see comment #43 and set it "false" instead of "true") and file a new bug in case.

Thanks everyone.