Bug 356938

> Now, I am not sure how to find what's causing this performance gap, I have tried to disable compositing in KDE (Alt+Shift+F12), this made no difference to the in-game FPS.

So, kwin is pretty much likely *not* the reason (does it run on the nvidia or the intel chip btw?)

Did you check CPU load of (other, desktop related) processes (baloo?)
Did you try to kill plasmashell? (keep yourself a konsole open ;-)

Also dump the environment of the game process:
    tr '\0' '\n' < /proc/[cs pid here]/environ

kwin runs on the intel chip.
baloo is disabled.

The only processes that seem to use CPU are the game, Steam and plasmashell.

I have tried to kill plasmashell, and it looks like the FPS immediately went to the same level as Gnome! Then, something interesting I could reproduce multiple times:
1) ALT-F2 -> plasmashell
2) I go back to CS GO, the performance is still the best one
3) I ALT-TAB back to desktop, then go back to CS GO, the performance is back to the "bad one"

I have to kill plasmashell again to get the best performance, and can launch it once again, but if I then ALT-TAB out from the game, it brings the bad performance back.

Created attachment 96208 [details]
CS GO environment variables

Apparently I might not be the only one with the same issue:
https://bugs.kde.org/show_bug.cgi?id=356366

Please note that I also need to disable compositing to have the same perf as Gnome. So basically, two issues:
1) The performance issue caused by ALT-TAB and requiring me to kill plasmashell
2) Compositing, which is also causing some performance loss in the game (although less than the first issue). I guess that could be solved with "Suspend compositor for fullscreen window"? Unfortunately since the main card is an intel card, the option is unavailable for me.

Sounds indeed like an exact duplicate, but on different HW/driver.

Try to
   export __GL_YIELD="NOTHING"
for the game, but since plasmashell will likely run on the intel chip as well, that *should* not be too troublesome. It will rather be because of the optimus pipe being blocked on the intel side because of "things plasmashell does in its opengl context™"

As a quick solution for the WE, simply
pkill -SIGTOP plasmashell
# run game
pkill -CONT plasmashell

would hopefully do?

Alternatively, can you disable optimus and run the nvidia GPU exclusively, resp. only optirun palsmashell as well (maybe it does better on switching/sharing active contexts)?

As for the kwin side, set up a rule to block compositing for the window.
See bug #348156 for further discussions on this (aside similar context sharing issues, kwin also caps MaxFPS and sync'd swaps)

PS:
> __GL_THREADED_OPTIMIZATIONS=1

Is that set by steam or yourself? Can you get rid of it?

export __GL_YIELD="NOTHING" doesn't seem to change anything

Sending the STOP signal to plasmashell seem to work.

Running everything on the nvidia GPU isn't really a solution, I used to do this but this kill the battery, and make the fans spin faster. Tried to "primusrun plasmashell", and the bug is still present, it doesn't help.

I am seeing the same behaviour as in bug #356366, if I click on the CS GO window to come back from the ALT-TAB, I get the bug, but if I over some other icon on the task bar (like Dolphin) and use ALT-TAB to get back in-game, I don't have the bug.

I went to kwin window rules, but I can't find any option to block compositing for the window. Or maybe it's called differently here?

__GL_THREADED_OPTIMIZATIONS=1 is set in the game launch script by default in all Source games, because there is a "Multicore rendering" option in the game settings which improve FPS and works with it. If I get rid of it, I would surely have lower FPS as that option would no longer work.

(In reply to AnAkkk from comment #9)
> Running everything on the nvidia GPU isn't really a solution

I rather meant "for a test" - to see whether it's optimus related reg. management of multiple contexts.

> I am seeing the same behaviour as in bug #356366, if I click on the CS GO
> window to come back from the ALT-TAB, I get the bug, but if I hover some
> other icon on the task bar (like Dolphin) and use ALT-TAB to get back
> in-game, I don't have the bug.

Hovering will likely get you a tooltip (becoming the active plasmashell context) and when switching, the tooltip closes (and the active/dominant context becomes the game)

> I went to kwin window rules, but I can't find any option to block
> compositing for the window. Or maybe it's called differently here?

Last tab (appearance and fixes), last item "block compositing" (I've unfortunately no idea how it's called in the french translation)

> __GL_THREADED_OPTIMIZATIONS=1 is set in the game launch script by default in

While __GL_THREADED_OPTIMIZATIONS should get you a benefit on multicore systems, I doubt it has actual impact on multicore rendering (which should work just as much)

Also I meant "for trying impact" - and you'd still rather get superior rendering compared to the present situation (if that has impact on the problem, we don't yet know the actual problem - except for maybe trouble on GL context management; apparently it's not limited to optimus - the other bug is iirc on fglrx)

(In reply to Thomas Lübking from comment #10)
> (In reply to AnAkkk from comment #9)
> > Running everything on the nvidia GPU isn't really a solution
> 
> I rather meant "for a test" - to see whether it's optimus related reg.
> management of multiple contexts.
> 

I'll try running everything on the Nvidia card later, this is a bit annoying to setup.

> > I went to kwin window rules, but I can't find any option to block
> > compositing for the window. Or maybe it's called differently here?
> 
> Last tab (appearance and fixes), last item "block compositing" (I've
> unfortunately no idea how it's called in the french translation)

I see, the translation doesn't really match, it actually says "Compositing by blocks" in French :D (like "a block of wood")
I just tried this option, and it sent a SIGSTOP message the kwin_x11 process apparently, making me totally unable to ALT-TAB, and even after putting back kwin_x11 in a normal state, it just wouldn't work, I had to use kwin_x11 --replace.

> > __GL_THREADED_OPTIMIZATIONS=1 is set in the game launch script by default in
> 
> While __GL_THREADED_OPTIMIZATIONS should get you a benefit on multicore
> systems, I doubt it has actual impact on multicore rendering (which should
> work just as much)

Removing __GL_THREADED_OPTIMIZATIONS doesn't actually change anything, it doesn't solve the issue and doesn't change the FPS either apparently.

(In reply to AnAkkk from comment #11)

> I see, the translation doesn't really match, it actually says "Compositing
> by blocks" in French :D (like "a block of wood")

*lol* - no, tile based deferred rendering is an attribute of the hardware, we cannot control that ;-)

Can you please file a bug against i18n/french?

> I just tried this option, and it sent a SIGSTOP message the kwin_x11 process
> apparently
No, that's drkonqi - kwin apparently crashed, but that won't be related to the setting (coincident) (see bug #353428) - SIGCONT will then just abort the kwin process (you may now have a stale drkonqi process around)

(In reply to Thomas Lübking from comment #12)

> Can you please file a bug against i18n/french?

Should it be frameworks-ki18n or ki18n?

> > I just tried this option, and it sent a SIGSTOP message the kwin_x11 process
> > apparently
> No, that's drkonqi - kwin apparently crashed, but that won't be related to
> the setting (coincident) (see bug #353428) - SIGCONT will then just abort
> the kwin process (you may now have a stale drkonqi process around)

Indeed, I do have a drkonqi process. It crashes every time I try to use that setting though.

I have tried to run everything in the nvidia card, but it's not actually possible anymore due to a bug in Xorg 1.18, which requires me to use a workaround, but then all windows are unusable, including the game menus (no cursor), see https://bugs.archlinux.org/task/47151
I tried to downgrade Xorg, but then I had files conflicting with my Nvidia packages...so I ended up just reverting all changes I've made :/

(In reply to AnAkkk from comment #13)
> Should it be frameworks-ki18n or ki18n?

Just "i18n" - ki18n is the translation infrastructure, not the translated strings.
I filed a bug and attached you, I cannot really handle this (my french is by far not good enough to lector others ;-)
 
> Indeed, I do have a drkonqi process. It crashes every time I try to use that
> setting though.
Can you gdb into the stopped kwin process and obtain a backtrace?

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope # allow attaching gdb
gdb --pid PID_OF_STOPPED_KWIN 2>&1 | tee stopped_kwin.gdb
thread apply all bt

(In reply to Thomas Lübking from comment #14)
> Just "i18n" - ki18n is the translation infrastructure, not the translated
> strings.
> I filed a bug and attached you, I cannot really handle this (my french is by
> far not good enough to lector others ;-)

Thanks :)

> echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope # allow attaching gdb
> gdb --pid PID_OF_STOPPED_KWIN 2>&1 | tee stopped_kwin.gdb
> thread apply all bt


Thread 4 (Thread 0x7fb6d52af700 (LWP 3797)):
#0  0x00007fb6ec88f18d in poll () from /usr/lib/libc.so.6
#1  0x00007fb6eab7fae2 in ?? () from /usr/lib/libxcb.so.1
#2  0x00007fb6eab81757 in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#3  0x00007fb6d5b51379 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#4  0x00007fb6eae3db8e in ?? () from /usr/lib/libQt5Core.so.5
#5  0x00007fb6ecb5a4a4 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007fb6ec89813d in clone () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7fb6cf678700 (LWP 3845)):
#0  0x00007fb6ec890e23 in select () from /usr/lib/libc.so.6
#1  0x00007fb6eb070c1f in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib/libQt5Core.so.5
#2  0x00007fb6eb0726f7 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib/libQt5Core.so.5
#3  0x00007fb6eb072bfe in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#4  0x00007fb6eb01c57a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#5  0x00007fb6eae38be4 in QThread::exec() () from /usr/lib/libQt5Core.so.5
#6  0x00007fb6e5af8055 in ?? () from /usr/lib/libQt5Qml.so.5
#7  0x00007fb6eae3db8e in ?? () from /usr/lib/libQt5Core.so.5
#8  0x00007fb6ecb5a4a4 in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fb6ec89813d in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0x7fb6ccac8700 (LWP 3855)):
#0  0x00007fb6ecb6007f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fb6e9fa1934 in ?? () from /usr/lib/libQt5Script.so.5
#2  0x00007fb6e9fa1979 in ?? () from /usr/lib/libQt5Script.so.5
#3  0x00007fb6ecb5a4a4 in start_thread () from /usr/lib/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#4  0x00007fb6ec89813d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7fb6ecfa7840 (LWP 3796)):
#0  0x00007fb6ec86791d in nanosleep () from /usr/lib/libc.so.6
#1  0x00007fb6ec8677b4 in sleep () from /usr/lib/libc.so.6
#2  0x00007fb6e5617d8a in ?? () from /usr/lib/libKF5Crash.so.5
#3  0x00007fb6e561821b in KCrash::defaultCrashHandler(int) () from /usr/lib/libKF5Crash.so.5
#4  <signal handler called>
#5  0x00007fb6ec44cdfd in ?? () from /usr/lib/libkwin.so.5
#6  0x00007fb6eb04e200 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#7  0x00007fb6eb9119ac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#8  0x00007fb6eb916e86 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#9  0x00007fb6eb01ebab in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#10 0x00007fb6eb020fa6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#11 0x00007fb6eb072ac2 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#12 0x00007fb6d5bb821d in ?? () from /usr/lib/libQt5XcbQpa.so.5
#13 0x00007fb6eb01c57a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#14 0x00007fb6eb02453c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#15 0x00007fb6ecd757cb in kdemain () from /usr/lib/libkdeinit5_kwin_x11.so
#16 0x00007fb6ec7cf610 in __libc_start_main () from /usr/lib/libc.so.6
#17 0x00000000004007c9 in _start ()


Unfortunately there are no debug symbols on Arch :/

I removed the "strip" option and recompiled kwin:

#5  0x00007f14261c462d in KWin::SceneOpenGLShadow::~SceneOpenGLShadow() () from /usr/lib/libkwin.so.5

From what I can see it's crashing because the "effects" pointer is NULL inside the SceneOpenGLShadow::~SceneOpenGLShadow destructor.

(In reply to AnAkkk from comment #17)
> From what I can see it's crashing because the "effects" pointer is NULL
> inside the SceneOpenGLShadow::~SceneOpenGLShadow destructor.


Ewwww. It somehow updates its shadow on creation (god knows why)
Can you try

diff --git a/shadow.cpp b/shadow.cpp
index 99f89bf..6963334 100644
--- a/shadow.cpp
+++ b/shadow.cpp
@@ -338,7 +338,7 @@ bool Shadow::updateShadow()
             m_topLevel->effectWindow()->sceneWindow()->updateShadow(0);
             m_topLevel->effectWindow()->buildQuads(true);
         }
-        deleteLater();
+//         deleteLater();
     };
     if (m_decorationShadow) {
         if (Client *c = qobject_cast<Client*>(m_topLevel)) {


This will leak, but if it doesn't crash we know
a) the cause
b) effects isn't reliable on the destructor (so checking it is justified - i'd prefer to not poke around and test "if (effects)" w/o actually knowing why it can be nullptr here)

Thanks for the investigation.

Thanks, this patch actually fix the crash :) Now it correctly disables compositing when launching CS GO.

Thanks for testing, please revert that patch and use https://git.reviewboard.kde.org/r/126441/ instead.

Ok :) Do you have any idea how I can debug the plasmashell performance issue?

Localize it in the known oddity.
Is it the taskbar tooltip (disable it and check whether the trick still works) or just the hover.
Is it maybe actually the taskbar (remove it).

Disabled the taskbar tooltip, the bug is still present. 
As long as I hover on "CS GO" in the taskbar, and:
1) click to put the game in front
or
2) alt-tab to put the game in front
the bug appears.

If I hover anything else in the task bar (an icon of a not running program, or any running app other than CS GO), and then ALT-TAB back into the game, it fixes the bug.

Sounds a lot like the taskbar reaction to hovering a particular entry/entry with certain attributes.
Is the game minimized at this time?
Does it affect other minimized taskbar entries?
Is it the active window (would eg. activating sth. else like xterm or so change something)?

(In reply to Thomas Lübking from comment #24)
> Sounds a lot like the taskbar reaction to hovering a particular entry/entry
> with certain attributes.
> Is the game minimized at this time?

Yes, when I ALT-TAB it minimizes it, I can't click on the task bar if it's not minimized.

> Does it affect other minimized taskbar entries?

What do you mean? Other entries are not games, so I can't really see any framerate change.

> Is it the active window (would eg. activating sth. else like xterm or so
> change something)?

I'm not sure what you mean, if I'm in-game, shouldn't it be the active window?

(In reply to AnAkkk from comment #25)

> What do you mean? Other entries are not games, so I can't really see any
> framerate change.

I meant "what if you hover the taskbar button of another minimized window" (oc. if you should only show minimized windows in the taskbar, that's answered)

> I'm not sure what you mean, if I'm in-game, shouldn't it be the active
> window?

Game -> alt+tab -> activate "something" (eg. xterm should be unsuspicious) -> hover the games taskbar entry -> activate the game (in either way, alt+tab or click the taskbar button)

Assigning to taskbar, since it seems to be the culprit ("somehow")

Btw, does it also happen with the "icons-only" taskbar?

Can someone sum up how exactly the Task Manager is supposed to be involved here? 26 comments is a lot to read.

(In reply to Thomas Lübking from comment #26)
> I meant "what if you hover the taskbar button of another minimized window"
> (oc. if you should only show minimized windows in the taskbar, that's
> answered)

Minimized or not, this fixes the issue, as in comment #23, as long as I over anything else than CS GO.

> Game -> alt+tab -> activate "something" (eg. xterm should be unsuspicious)
> -> hover the games taskbar entry -> activate the game (in either way,
> alt+tab or click the taskbar button)

Alt-tabbed, I launched xterm through the task bar, then hovered the game taskbar entry, and I had the bug again when going back in-game.

> Btw, does it also happen with the "icons-only" taskbar?

I have added an icons-only taskbar, and the issue is exactly the same. What I actually noticed is that I need to apply my "fix" to both taskbars, otherwise I get the issue. This means I need to hover something else than CS GO on both taskbars.

Also tried to hover another window on the task bar, and to use the mouse wheel to switch between windows, and it fixes the bug since I am hovering something else. If I hover CS GO and do the same, I have the same issue again.

So apparently as long as the last hovered window on the taskbar is the CS GO, in any case, I get the performance issue.

errrr... Eike, why do i see a live preview in the taskbar tooptip *even with compositing disabled*?
Does the taskbar redirect windows itself (in doubt)?

AFAIK yes, the WindowThumbnail component (written by Martin) doesn't need kwin.

Yes, WindowThumbnail hooks into Composite on its own.

Sounds suspicious enough (despite disabling tooltips seems to make no difference; i'd assume the window is redirected as long as the entry is hovered and it misses the leave event when the FS window kicks above it)

@AnAkk, find /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml and in there the PlasmaCore.ToolTipArea branch (line 166-212 here)
Comment or delete it (keep a copy ;-)
Restart plasmashell and see what happens.

PS, comment works C-style

/* PlasmaCore.ToolTipArea {
   blablablah;
} */

I can confirm that this also fixes the issue :)

So, despite being disabled by setting, the model for the toolbuttons is still created and apparently queried (causing the overhead that explains the FPS drop)

Why am I not surprised?

Given the past descriptions, it's also that some index is always current (and thus the related window is redirected) - that's why one has to hover some other taskbar entry (to redirect that window, which will not mess with the games gl context, nor likely cause damage events at 120Hz)

Setting "currentIndex: -1" when the tooltip closes (or, in doubt, when the pointer leaves the taskbar) should likely do, but how does one "declare" such? (Does one at all?)

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

Git commit c64a94a265acd5003fbbb4e3abc7fdb72726b4c3 by Eike Hein.
Committed on 22/12/2015 at 18:26.
Pushed by hein into branch 'master'.

Stop redirecting windows when item is disabled or hidden.

Concretely fixes Task Manager tooltips slowing down app rendering even
after the tooltip is hidden.

REVIEW:126475

M  +19   -1    src/declarativeimports/core/windowthumbnail.cpp

http://commits.kde.org/plasma-framework/c64a94a265acd5003fbbb4e3abc7fdb72726b4c3

See also https://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=ae00bbea02dd4b245efc00571840ecdbc7d3da4c

Thanks for the fix :)

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

(In reply to Thomas Lübking from comment #20)
> Thanks for testing, please revert that patch and use
> https://git.reviewboard.kde.org/r/126441/ instead.

Is there any thing new on merging this? :)

(In reply to AnAkkk from comment #42)

> Is there any thing new on merging this? :)


not been approved yet - i guess martin's still catching up x-mas vacancies.

Git commit cae90bb035e6170a9beb38545cf60e31af612804 by Thomas Lübking.
Committed on 16/02/2016 at 12:59.
Pushed by luebking into branch 'master'.

catch nullptr effects when deleting shadows

the shadow can be deleted deferred from an update
there's a slight chance, to be eg. triggered by clients
blocking compositing, that the compositor is suspended in the same
cycle and the effects pointer (and scene and context) thus gone
FIXED-IN: 5.6
REVIEW: 126441

M  +5    -3    scene_opengl.cpp

http://commits.kde.org/kwin/cae90bb035e6170a9beb38545cf60e31af612804