Bug 329297 - Kwin very slow/frozen when OpenGL compositing enabled
Summary: Kwin very slow/frozen when OpenGL compositing enabled
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Unclassified
Component: compositing (show other bugs)
Version: 4.11.4
Platform: openSUSE RPMs Linux
: NOR major (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-28 04:08 UTC by Chris Wilkinson
Modified: 2014-01-29 09:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Wilkinson 2013-12-28 04:08:15 UTC
Kwin OpenGL compositing in KDE 4.12.0  causes my KDE desktop to slow or freeze soon (10-20 seconds) after enabling with Ctrl-Alt-F12 the desktop effects. I'm using NVidia proprietary driver 331.20 x64. If I run ksysguard there is no increase in CPU (AMD Phenom 2 1090T 3.2GHZ 6 core) or RAM (8GB DDR3) use, but I hear the fans on my GPU GeForce GTX 560Ti 1GB spool up a little almost immediately after the performance begins to slow. The same hardware and NVidia driver worked very well with KDE 4.9.5, and full OpenGL compositing enabled.
Comment 1 Thomas Lübking 2013-12-28 06:25:36 UTC
please provide the output of "qdbus org.kde.kwin /KWin supportInformation" (ideally with GL compositing  enabled)

Also try whether setting tearing prevention to "none" ("kcmshell4 kwincompositing", 3rd tab) and exporting KWIN_USE_BUFFER_AGE=0 has any impact.
Comment 2 Martin Flöser 2013-12-28 08:09:45 UTC
> and exporting KWIN_USE_BUFFER_AGE=0 has any
> impact.
That's not yet in a release, isn't it? It's for 4.11.5 and that's not yet 
released. 4.12.0 doesn't exist in kde-workspace, so at max it's 4.11.4.
Comment 3 Chris Wilkinson 2013-12-28 08:25:11 UTC
Output of "qdbus org.kde.kwin /KWin supportInformation" follows...

Version
=======
KWin version: 4.11.4
KDE SC version (runtime): 4.12.0
KDE SC version (compile): 4.12.0
Qt Version: 4.8.5

Options
=======
focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 250
separateScreenFocus: false
placement: 4
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
showDesktopIsMinimizeAll: false
rollOverDesktops: true
focusStealingPreventionLevel: 1
legacyFullscreenSupport: false
operationTitlebarDblClick: 
commandActiveTitlebar1: 0
commandActiveTitlebar2: 30
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 30
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
showGeometryTip: false
condensedTitle: false
electricBorderMaximize: true
electricBorderTiling: true
electricBorderCornerRatio: 0.25
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: true
inactiveTabsSkipTaskbar: false
autogroupSimilarWindows: false
autogroupInForeground: true
compositingMode: 1
useCompositing: true
compositingInitialized: true
hiddenPreviews: 1
unredirectFullscreen: false
glSmoothScale: 2
colorCorrected: false
xrenderSmoothScale: false
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glDirect: true
glStrictBinding: false
glStrictBindingFollowsDriver: true
glLegacy: false
glCoreProfile: false
glPreferBufferSwap: 99

Screen Edges
============
desktopSwitching: false
desktopSwitchingMovingClients: false
cursorPushBackDistance: 
timeThreshold: 150
reActivateThreshold: 350
actionTopLeft: 0
actionTop: 0
actionTopRight: 0
actionRight: 0
actionBottomRight: 0
actionBottom: 0
actionBottomLeft: 0
actionLeft: 0

Screens
=======
Multi-Head: no
Active screen follows mouse:  no
Number of Screens: 1
Screen 0 Geometry: 0,0,2560x1440

Decoration
==========
Current Plugin: kwin3_oxygen
Shadows: yes
Alpha: yes
Announces Alpha: yes
Tabbing: yes
Frame Overlap: no
Blur Behind: no

Compositing
===========
Qt Graphics System: raster
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL version string: 4.4.0 NVIDIA 331.20
OpenGL shading language version string: 4.40 NVIDIA via Cg compiler
Driver: NVIDIA
Driver version: 331.20
GPU class: GF100
OpenGL version: 4.4
GLSL version: 4.40
X server version: 1.14.3
Linux kernel version: 3.11.6
Direct rendering: yes
Requires strict binding: no
GLSL shaders:  yes
Texture NPOT support:  yes
Virtual Machine:  no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace:  no

Loaded Effects:
---------------
kwin4_effect_zoom
kwin4_effect_slidingpopups
kwin4_effect_login
kwin4_effect_minimizeanimation
kwin4_effect_screenshot
kwin4_effect_slide
kwin4_effect_desktopgrid
kwin4_effect_translucency
kwin4_effect_maximize
kwin4_effect_cooleffect
kwin4_effect_fade
kwin4_effect_highlightwindow
kwin4_effect_taskbarthumbnail
kwin4_effect_dialogparent
kwin4_effect_presentwindows
kwin4_effect_blur
kwin4_effect_logout
kwin4_effect_dashboard
kwin4_effect_screenedge
kwin4_effect_startupfeedback
kwin4_effect_kscreen

Currently Active Effects:
-------------------------
kwin4_effect_blur

Effect Settings:
----------------
kwin4_effect_zoom:
zoomFactor: 1.2
mousePointer: 0
mouseTracking: 0
enableFocusTracking: false
followFocus: true
focusDelay: 350
moveFactor: 20
targetZoom: 1

kwin4_effect_slidingpopups:
fadeInTime: 250
fadeOutTime: 250

kwin4_effect_login:

kwin4_effect_minimizeanimation:

kwin4_effect_screenshot:

kwin4_effect_slide:

kwin4_effect_desktopgrid:
zoomDuration: 300
border: 10
desktopNameAlignment: 0
layoutMode: 0
customLayoutRows: 2
usePresentWindows: true

kwin4_effect_translucency:

kwin4_effect_maximize:

kwin4_effect_cooleffect:

kwin4_effect_fade:

kwin4_effect_highlightwindow:

kwin4_effect_taskbarthumbnail:

kwin4_effect_dialogparent:

kwin4_effect_presentwindows:
layoutMode: 0
showCaptions: true
showIcons: true
doNotCloseWindows: false
ignoreMinimized: false
accuracy: 20
fillGaps: true
fadeDuration: 150
showPanel: false
leftButtonWindow: 1
rightButtonWindow: 2
middleButtonWindow: 0
leftButtonDesktop: 2
middleButtonDesktop: 0
rightButtonDesktop: 0
dragToClose: false

kwin4_effect_blur:
blurRadius: 12
cacheTexture: true

kwin4_effect_logout:
useBlur: true

kwin4_effect_dashboard:
brightness: 0.5
saturation: 0.5
blur: false

kwin4_effect_screenedge:

kwin4_effect_startupfeedback:

kwin4_effect_kscreen:
Comment 4 Thomas Lübking 2013-12-28 11:24:24 UTC
(In reply to comment #2)
> That's not yet in a release, isn't it?
No, sorry. I assumed 4.12.0 would equal 4.11.5
*grummelbrummelstupidreleasefreezegrummelbrummel*

@Chris
Please try setting the tearing prevention to "none" nevertheless (that's gonna work ;-) and also to deactivate the blur effect.
Please ensure to restart "kwin --replace &" after altering the tearing prevention mode.

Next thing (even if that helps!) would be to check whether triple buffering is enabled:
grep -i triple /var/log/Xorg.0.log

And if not try results with:
---------------------------------
export __GL_YIELD="USLEEP"
kwin --replace &
Comment 5 Chris Wilkinson 2013-12-28 21:55:32 UTC
Hi Thomas,

(In reply to comment #4)
> (In reply to comment #2)
> > That's not yet in a release, isn't it?
> No, sorry. I assumed 4.12.0 would equal 4.11.5
> *grummelbrummelstupidreleasefreezegrummelbrummel*

;-)

> @Chris
> Please try setting the tearing prevention to "none" nevertheless (that's
> gonna work ;-) and also to deactivate the blur effect.
> Please ensure to restart "kwin --replace &" after altering the tearing
> prevention mode.

I'm not sure how to say this, but after not working since I installed openSUSE 13.1 over 4 days ago, OpenGL compositing in KDE seems to be working now. Or at least it has not caused any slow down or lock up since last night around when I uploaded the qdbus command output - it has also survived 2 cold reboots I did as a test this morning.

Blur is running, and tearing prevention is set to 'auto', and performance is as good as it was under KDE 4.9.5, which with my GeForce GTX 560Ti was very good...

> Next thing (even if that helps!) would be to check whether triple buffering
> is enabled:
> grep -i triple /var/log/Xorg.0.log

No mention of triple buffering in Xorg.0.log.
 
> And if not try results with:
> ---------------------------------
> export __GL_YIELD="USLEEP"
> kwin --replace &

I'll keep monitoring the performance, and if it slows again I'll look at usleep and other options, and report back to here.

Thanks guys, although I have no idea what actually fixed it - maybe it fixed itself somehow...

Best regards,

Chris W, NZ.
Comment 6 Thomas Lübking 2013-12-28 23:15:03 UTC
Ok, see this long bug #322060

Basically, when triple buffering is not available and usleep yielding not set, tearing prevention will be disabled.
Since there's no legal way to detect triple buffering, this might fail, leading kwin to believe it could swap for free, thus becoming rather sloppy about frame time calculation, running into long expensive waits for the swap interval.
Consider enabling triple buffering (bug #322060 comment #56) or exporting usleep yielding (see eg. script attached to bug #322060)

If the issue re-occurs any time, just re-open the bug.
Comment 7 Chris Wilkinson 2013-12-29 01:29:40 UTC
Hi there,

It was nice while it lasted, but then the issue came back a short while ago.

(In reply to comment #6)
> Ok, see this long bug #322060
> 
> Basically, when triple buffering is not available and usleep yielding not
> set, tearing prevention will be disabled.
> Since there's no legal way to detect triple buffering, this might fail,
> leading kwin to believe it could swap for free, thus becoming rather sloppy
> about frame time calculation, running into long expensive waits for the swap
> interval.
> Consider enabling triple buffering (bug #322060 comment #56) or exporting
> usleep yielding (see eg. script attached to bug #322060)
> 
> If the issue re-occurs any time, just re-open the bug.

I enabled triple buffer in xorg.conf, and after restarting X did "export __GL_YIELD="USLEEP" - that worked when I restarted kwin, so now I need to figure out where to add the __GL_YIELD command so it works on booting, any best suggestions? ;-)

Chris W, NZ
Comment 8 Chris Wilkinson 2013-12-29 02:08:00 UTC
Hi there,

> > If the issue re-occurs any time, just re-open the bug.
> 
> I enabled triple buffer in xorg.conf, and after restarting X did "export
> __GL_YIELD="USLEEP" - that worked when I restarted kwin, so now I need to
> figure out where to add the __GL_YIELD command so it works on booting, any
> best suggestions? ;-)

I answered my own question - I found a site that recommended adding it to /etc/profile, but the openSUSE version of that config file recommended strongly that anything to be put in there be added to /etc/profile.local instead, which I've now done. So after a reboot everything seems to be running fine.

I'll keep you posted to see if it sticks...

Best regards,

Chris W, NZ.
Comment 9 Thomas Lübking 2013-12-29 13:10:29 UTC
the dupe has a script attached that starts kwin and allows you to alter various env settings.
please notice that exporting the yield strategy globally will impact every gl application - games may reply that by dropping fps.
also yielding adjustment should not be necessary when triple buffering is enabled (as the driver never has to wait for the retrace)

*** This bug has been marked as a duplicate of bug 322060 ***
Comment 10 Thomas Lübking 2013-12-29 13:12:15 UTC
bug #329297 seems to have a false POSITIVE detection of triple buffering.
Comment 11 Chris Wilkinson 2013-12-30 23:16:00 UTC
Hi Thomas,

(In reply to comment #9)
> the dupe has a script attached that starts kwin and allows you to alter
> various env settings.
> please notice that exporting the yield strategy globally will impact every
> gl application - games may reply that by dropping fps.
> also yielding adjustment should not be necessary when triple buffering is
> enabled (as the driver never has to wait for the retrace)

I tried running just with triple buffering enabled, but eventually the problem seems to return, sometimes almost immediately, sometimes taking a bit longer (3-5 minutes). So I have re-enabled export __GL_YIELD="USLEEP" for now. Testing some games, and other OpenGL apps like the Unigine Valley demo they seem to run very good as I expect from previously, so if they are losing frames due to the yield strategy it is not bad enough for me to worry, or actually notice.

I have noticed that without yield strategy set, the problem seems more likely to be triggered by doing something that is KDE specific, like changing the wallpaper, opening the desktop config, or running other apps that are part of the KDE desktop environment - running non-KDE apps it seems the problem can stay away for a bit longer.

> *** This bug has been marked as a duplicate of bug 322060 ***

Looking at that bug report there are similarities, but logging CPU performance at no time is there any excess load on the Phenom 2 X6 - there is often an increase in fan speed on my GeForce card however. So I think this bug would be better shown as resolved, but rather as worksforme rather than duplicate?

I shall leave things for now, since the yield strategy seems to work well for me.

Regards,

Chris W, NZ.
Comment 12 Thomas Lübking 2013-12-31 22:02:22 UTC
The cpu load can happen in the kernel, but the (assumed, we should check that next year) false positive detection of triple buffering as well as triple buffering not resolving the issue alone (it does show up as active in /var/log/Xorg.0.log, does it?) is indeed suspicious.
Could be that the refreshrate/maxfps is misdetected/overridden, we should check for that as well ... next year ;-)

The core problem from our side (default yielding strategy causing "trouble™" for the nvidia blob) is however the same.
Comment 13 Chris Wilkinson 2014-01-01 00:06:03 UTC
Hi Thomas,

(In reply to comment #12)
> The cpu load can happen in the kernel, but the (assumed, we should check
> that next year) false positive detection of triple buffering as well as
> triple buffering not resolving the issue alone (it does show up as active in
> /var/log/Xorg.0.log, does it?) is indeed suspicious.

:~> grep -i triple /var/log/Xorg.0.log
[    22.835] (**) NVIDIA(0): Option "TripleBuffer" "1"

Its in xorg.conf for sure.

> Could be that the refreshrate/maxfps is misdetected/overridden, we should
> check for that as well ... next year ;-)
> 
> The core problem from our side (default yielding strategy causing "trouble™"
> for the nvidia blob) is however the same.

Between enabling triplebuffer and the yield strategy, my KDE desktop is behaving and performing at a level that is more than satisfactory. OpenGL/CUDA apps like octane render, nexuiz, valley and heaven benchmarks, prey, webgl stuff, and blender/cycles render, are working very well. I'm happy to let things sit where they are since they seem stable, but if you want to get to why triplebuffer alone doesn't fix the issue just point me in a direction and I'll do what I can to help.

Happy New Year,

Chris W, NZ.
Comment 14 Thomas Lübking 2014-01-01 02:46:11 UTC
It would be very good to know whether triple buffering is reliably detected on the system.
To do so, you'd have to run "kdebugdialog --fullmode", filter for kwin (1212) and redirect all output to some file, e.g. /tmp/kwin.dbg

The file will after a short time (500 screen updates) contain a "Triple buffering detection" line which will indicate whether triple buffering is assumed to be available and the mean blocking time of glSwapBuffers().

If this works as expected, we'd face a new change in the nvidia driver (it doesn't change the implication to get it to use the "proper" yielding, but it would nevertheless be good to know, what the critical call is)

Thanks in advance and
Happy New Year to you as well.