[krita] [Bug 347620] Performance degradation and UI glitchyness when using multiple views across multiple monitors

[Jonathan Ringstad via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347620

--- Comment #4 from Jonathan Ringstad  ---
Just tested with 3.0. It seems that the situation is better, but it's hard to
test, as krita constantly crashes in multi-window/multi-view mode.

Creating a document, creating a new window, then in that new window switching
to a view of the created document, then trying to paint in both windows
alternatingly makes the UI block up. As the UI blocks up, it pops open a
message "Group not editable".

With the mouse it does work (sorta?) and the performance seems fine then. With
the tablet, the UI locks up quickly, and then trying to close the document
makes the entire UI hang completely or even segfault.

I'm still observing the following things, however (which of these are bugs,
you'll have to make a decision on, I suppose -- but some of them are rather
unexpected, like the layer switching):

- when switching between windows to draw in, the preset changes (is it supposed
to be that way?)
- when switching between windows to draw in, even though the preset changes,
the outline of the preset remains the old one sometimes, so that you end up
painting with a different present than what your brush outline would suggest
you are using.
- the tool selected also changes (e.g. line-tool in the first window vs. brush
in the other)
- blending mode also changes
- different layers can be selected in different windows
- creating a new layer in one window breaks painting in the other, until one
selects a valid layer in the other window

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers

[Jonathan Ringstad via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343803

--- Comment #41 from Jonathan Ringstad  ---
I had a look and found a bit of additional information:

- The hang occurs when the libc exit handler cleans up the shared libraries of
the program, so when the process starts to hang, no actual konsole code is
running anymore. So that seems to make it very unlikely that the fault is with
konsole
- the hang occurs inside _nv014tls in /usr/lib/libnvidia-tls.so.358.16 (nvidias
thread-local storage library used by GL, GLX et al), where the function falls
into an infinite loop. Injecting a debugger and forcing it to return, results
in konsole exiting normally.
- The libc exit handler calls /usr/lib/libGL.so.1's .fini section (I think)
which calls the problematic _nv014tls from the libnvidia-tls.so.
- libGL gets loaded because konsole (well, Qt, I think -- konsole does not
touch GLX directly) wants to do glX* calls such as glXChooseFBConfig,
glXGetFBConfigAttrib, glXGetVisualFromFBConfig. no GLX context is ever
initialized or destroyed from what I can tell, however (which is a bit strange,
but I think should be perfectly legal to do. All the functions that are called
do not require a GLX context to be present, from what I can tell.)
- Re-running the exact same sequence of GLX functions in a different process
does not lead to such a hang. Traceback: http://dpaste.com/0RWSDK7 I re-ran the
traceback a few thousand times without a hang. So there's probably at least one
more ingredient necessary to make the hang happen.

That's about as far as I got. As a workaround it might be possible to make Qt
not interact with GLX (if that's possible), since it's not used anyway. It
seems pretty likely to me at this point that the bug is in the nvidia client
driver, but I suppose there is still a chance the bug is in Qt. I think the bug
is definitely not in konsole.

I didn't manage to produce a minimal test-case, unfortunately. To get there, it
might be useful to check if konsole loads any other nvidia client drivers, and
if yes, how it interacts with them.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers

[Jonathan Ringstad via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343803

--- Comment #42 from Jonathan Ringstad  ---
I had a look and found a bit of additional information:

- The hang occurs when the libc exit handler cleans up the shared libraries of
the program, so when the process starts to hang, no actual konsole code is
running anymore. So that seems to make it very unlikely that the fault is with
konsole
- the hang occurs inside _nv014tls in /usr/lib/libnvidia-tls.so.358.16 (nvidias
thread-local storage library used by GL, GLX et al), where the function falls
into an infinite loop. Injecting a debugger and forcing it to return, results
in konsole exiting normally.
- The libc exit handler calls /usr/lib/libGL.so.1's .fini section (I think)
which calls the problematic _nv014tls from the libnvidia-tls.so.
- libGL gets loaded because konsole (well, Qt, I think -- konsole does not
touch GLX directly) wants to do glX* calls such as glXChooseFBConfig,
glXGetFBConfigAttrib, glXGetVisualFromFBConfig. no GLX context is ever
initialized or destroyed from what I can tell, however (which is a bit strange,
but I think should be perfectly legal to do. All the functions that are called
do not require a GLX context to be present, from what I can tell.)
- Re-running the exact same sequence of GLX functions in a different process
does not lead to such a hang. Traceback: http://dpaste.com/0RWSDK7 I re-ran the
traceback a few thousand times without a hang. So there's probably at least one
more ingredient necessary to make the hang happen.

That's about as far as I got. As a workaround it might be possible to make Qt
not interact with GLX (if that's possible), since it's not used anyway. It
seems pretty likely to me at this point that the bug is in the nvidia client
driver, but I suppose there is still a chance the bug is in Qt. I think the bug
is definitely not in konsole.

I didn't manage to produce a minimal test-case, unfortunately. To get there, it
might be useful to check if konsole loads any other nvidia client drivers, and
if yes, how it interacts with them.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers

[Jonathan Ringstad via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343803

--- Comment #45 from Jonathan Ringstad  ---
That does indeed not fix the issue, as the issue is not with OpenGL but with
GLX. The GLX calls are made all the same. 

You can force software rendering through mesas llvm-pipe by adjusting your
library path to include the mesa libGL.so first (mesas llvm-pipe driver can
pretty much co-exist with any other driver without big issues -- useful for
testing), but that is a rather drastic measure and not a solution I would
recommend for end-users as workaround for several reasons.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers

[Jonathan Ringstad via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343803

--- Comment #31 from Jonathan Ringstad  ---
I believe I observed the breakpoint being triggered many times, but I'm not
sure how thoroughly I actually investigated that. I can collect more data later
today to (hopefully) answer the question definitely.

If it does indeed just hang in the  nvidia function without ever returning to
konsoles code, then I would agree that that makes it a much more likely
candidate for being a bug in the driver; but that's still not entirely a sure
thing.

I can try to make a debug-build of konsole to isolate the driver<->konsole
transitioning site, but I'm not sure if I'll have time this week.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers

[Jonathan Ringstad via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=343803

--- Comment #28 from Jonathan Ringstad  ---
We really don't know anything about where the issue is. All we know is that a
function from the nvidia driver is getting called repeatedly, and that's where
CPU time is going. I can easily invent a dozen scenarios that would cause this
type of behaviour, yet it would still be my fault (the simplest being to just
call whatever driver function in an infinite loop.)

Seeing how the nvidia driver is generally very solidly engineered (the most
reliable of all drivers by a HUGE margin, in my experience) I see no particular
reason to assume it's the drivers fault.

-- 
You are receiving this mail because:
You are watching all bug changes.