Bug 330986

Summary: nouveau: Graphical corruption in logout effect blur shader
Product: [Plasma] kwin Reporter: AnAkkk <anakin.cs>
Component: effects-variousAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED UPSTREAM    
Severity: normal CC: anakin.cs
Priority: NOR Flags: thomas.luebking: nouveau+
thomas.luebking: ReviewRequest+
Version: 4.11.6   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
URL: https://git.reviewboard.kde.org/r/115762/
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: glxinfo
kwin supportinformation
select minimum samples
fixed "select minimum samples"
kwin.dbg
One more "select minimum samples"
msaa patch
msaa patch, printing visuals

Description AnAkkk 2014-02-10 16:28:11 UTC
When the desktop logout effect is enabled, if I try to shutdown/restart/log out, the window with the countdown opens and show up correctly, but the background is corrupted with random stuff such as windows/menus that were opened before, or even currently opened windows but totally reversed and/or at different places. 
Unfortunately, it doesn't look like I can take a screenshot while that screen is open.
This only happens with the nouveau driver with OpenGL compositing. It works fine with XRender, or if I use the proprietary nvidia driver with OpenGL.

It has been reported in nouveau bug tracker as well:
https://bugs.freedesktop.org/show_bug.cgi?id=74316
I was told by a nouveau developer that it would need help from KDE devs to debug the issue. Martin told me to report it here.

Reproducible: Always
Comment 1 Thomas Lübking 2014-02-10 17:09:00 UTC
could be bug #330307 - do you have a camera/smartphone to take a "screenshot"?
Comment 2 AnAkkk 2014-02-10 18:00:04 UTC
Isn't https://bugs.kde.org/show_bug.cgi?id=330307 fixed by latest update?
Yes, I can take a photo, I'll only be able to access that computer next Friday though.
Comment 3 Thomas Lübking 2014-02-10 20:10:17 UTC
Yes, missed the "4.11.6" in this report - sorry.

You can also try
   kwriteconfig --file kwinrc --group Effect-Logout --key UseBlur false
(then restart the compositor, "Shift+Alt+F12" twice)
Comment 4 AnAkkk 2014-02-14 16:38:28 UTC
Indeed, that does fix it :)
Anything else I should do to help fix the issue?
Comment 5 Thomas Lübking 2014-02-14 16:51:33 UTC
run kwin from konsole and redirect all output into some file, resp. inspec the dmesg output for error messages from MESA regarding the shader.

You can also export various MESA environments, notably MESA_DEBUG and MESA_GLSL, see http://www.mesa3d.org/envvars.html

Nouveau will also require to compare with the SW rendering:
export LIBGL_ALWAYS_SOFTWARE=1
kwin --replace & # this is gonna be rather slow

In any case, please attach the output of "qdbus org.kde.kwin /KWin supportInformation" and/or "glxinfo" (for precise information about the renderer and render path)
Comment 6 AnAkkk 2014-02-14 17:32:42 UTC
Created attachment 85150 [details]
glxinfo
Comment 7 AnAkkk 2014-02-14 17:32:52 UTC
kwin just crashes, it restarts and then desktop effects don't work if I use LIBGL_ALWAYS_SOFTWARE=1.

Anyway when I reproduce the issue, this floods my terminal:
kwin(1019) KWin::checkGLError: GL error ( Render blur texture ):  "GL_INVALID_OPERATION" 

$ qdbus org.kde.kwin /KWin supportInformation
qdbus: could not exec '/usr/lib/qt/bin/qdbus': No such file or directory
(doesn't seem to work on my system for some reason)
Comment 8 Thomas Lübking 2014-02-14 17:34:56 UTC
try "qdbus-qt4"
Comment 9 AnAkkk 2014-02-14 17:35:57 UTC
Created attachment 85151 [details]
kwin supportinformation

It works with qdbus-qt4.
Comment 10 Thomas Lübking 2014-02-14 17:38:34 UTC
> glCoreProfile: true

Same issue when choosing "OpenGL 2" in the third tab of "kcmshell4 kwincompositing"?
Comment 11 AnAkkk 2014-02-14 17:41:50 UTC
Indeed, the issue is the same. With OpenGL 1.2, it's worse, almost all of the background turns black when I try to logout, and it shows a different error:
kwin(811) KWin::checkGLError: GL error ( PostPaint ):  "GL_INVALID_OPERATION"
Comment 12 AnAkkk 2014-02-14 17:55:16 UTC
Here's the error from mesa with MESA_DEBUG=1 and LIBGL_DEBUG=1:
Mesa: User error: GL_INVALID_OPERATION in glBlitFramebufferEXT(bad src/dst multisample pixel formats)
Comment 13 AnAkkk 2014-02-14 18:03:28 UTC
Looks like the same issue was previously reported here:
https://bugs.kde.org/show_bug.cgi?id=309510
Comment 14 Thomas Lübking 2014-02-14 20:15:42 UTC
@Martin,Fredrik
I don't see particular entries for GLX_SAMPLE_BUFFERS  / GLX_SAMPLES  in the attribs list for glXChooseFBConfig, nor search introduced by http://commits.kde.org/kde-workspace/6cf057777555a5d0c834de3a0165a62916cf3b40, fixing bug #308385

-> No longer required? Or are we evtl. selecting MSAA drawables again?

In addition there seems no 32 depth GLXFBConfigs in the provided glxinfo


@AnAkkk
Are you using kwin on GLX? (or kwin_gles, resp. selected the EGL like
   export KWIN_OPENGL_INTERFACE=egl
)?

"kdebugdialog" - enable 1212 (kwin) and see whether there's an error message like 

   "Could not find a framebuffer configuration for depth 32."

resp. post the output part that starts with:
   "Drawable visual (depth "
Comment 15 AnAkkk 2014-02-14 20:36:05 UTC
I'm using GLX. I just tried with EGL, and I didn't have the issue.

1212 (kwin) was already enabled.

I don't have the error you mentionned.

kwin(16011) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
kwin(16011) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth  24 ): 0x "153"
kwin(16011) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth  32 ): 0x "73"
kwin(16011) KWin::GlxBackend::initBuffer: Buffer visual (depth  24 ): 0x "168"
Comment 16 Thomas Lübking 2014-02-14 20:51:23 UTC
(In reply to comment #15)

> kwin(16011) KWin::GlxBackend::initBuffer: Buffer visual (depth  24 ): 0x
> "168"

0x168 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  2 1 None
                                                                                                    ^^^^
Should be 0x157 (no sample buffers)

Can you compile and try a patch?
Comment 17 AnAkkk 2014-02-14 20:56:27 UTC
Sure, I can try.
Comment 18 Thomas Lübking 2014-02-14 21:39:19 UTC
Created attachment 85153 [details]
select minimum samples

Patch attached, should cleanly apply on 4.11.6
Comment 19 AnAkkk 2014-02-14 22:41:34 UTC
Well that patch just cause kwin to freeze up, I can see the mouse moving but everything else is stuck. Launching kwin --replace & in a terminal just keep showing:
KWin::checkGLError: GL error ( PostPaint ): "GL_INVALID_OPERATION"
Comment 20 AnAkkk 2014-02-14 22:43:58 UTC
MESA_DEBUG shows:
GL_INVALID_OPERATION in glCopyTexSubImage2D(missing readbuffer, format=0x1908)
Comment 21 Thomas Lübking 2014-02-14 22:47:58 UTC
Created attachment 85154 [details]
fixed "select minimum samples"

F*** - cnp bug, the iterator is "j" in the second loop.
Sorry.
Comment 22 AnAkkk 2014-02-14 23:01:05 UTC
Same issue as with the previous patch.
Comment 23 Thomas Lübking 2014-02-14 23:08:20 UTC
What's the corresponding debug output (as provided in comment #15)?
No debug out like
"Could not find a framebuffer configuration"
or
"Failed to find a usable framebuffer configuration"?
Comment 24 AnAkkk 2014-02-14 23:23:26 UTC
Well, when I launch kwin from a VT there seem to be a lot less debug output, there aren't any messages starting by KWin::Compositor or KWin::GlxBackend.
Comment 25 Thomas Lübking 2014-02-14 23:27:22 UTC
forgot to "export DISPLAY=:0"?
In doubt you can
   kwin > kwin.dbg 2>&1 
from konsole and check kwin.dbg afterwards.
Comment 26 AnAkkk 2014-02-14 23:33:14 UTC
Created attachment 85156 [details]
kwin.dbg

I can't really do that from konsole as the screen is totally stuck/unusable.
Comment 27 Thomas Lübking 2014-02-14 23:45:51 UTC
Created attachment 85157 [details]
One more  "select minimum samples"

odd -  glCopyTexSubImage2D seems to be only called in the lanczos filter and the blur effect, but the debug output does not suggest that the compositor was started at all.
you could gdb into kwin and check whether it hangs in some function which initialising OpenGL.

Attached one more variant of the patch (the second config query contained a break, ie. was actually not searching for the minimum samples)
Comment 28 AnAkkk 2014-02-15 10:12:58 UTC
Still the same. The first time I do a kwin --replace & from a VT, there are actually a few X errors:
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 20 (X_GetProperty)
  Resource id: 0x180001d
(shows up twice)

gdb back trace:
#0  0x00007f6934c58fd3 in select () from /usr/lib/libc.so.6
#1  0x00007f692efec49b in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) () from /usr/lib/libQtCore.so.4
#2  0x00007f692eff1ac4 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timeval*) () from /usr/lib/libQtCore.so.4
#3  0x00007f692eff1f12 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f692e1e6b36 in ?? () from /usr/lib/libQtGui.so.4
#5  0x00007f692efc0b1f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f692efc0e15 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#7  0x00007f692efc5f4b in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#8  0x00007f6934f9d7d6 in kdemain () from /usr/lib/libkdeinit4_kwin.so
#9  0x00007f6934b9bb05 in __libc_start_main () from /usr/lib/libc.so.6
#10 0x00000000004006fe in _start ()
Comment 29 AnAkkk 2014-02-15 10:21:44 UTC
That was thread #1.
Thread #2 waits on a select() call from libQtCore.so.4.
Thread #3 called QProcess::execute which called QProcess::waitForFinished from libkdeinit4_kwin.so, so I guess it's still waiting for whatever process it executed.
Comment 30 AnAkkk 2014-02-15 10:26:26 UTC
Well now for some reason kwin works, I haven't changed anything...Desktop effects don't seem to work though, and I can't enable them with Shift+ALT+F12. This error shows up:
kwin(1155): Compositing is not possible
Comment 31 AnAkkk 2014-02-15 12:15:48 UTC
kwin still get stuck from time to time, it seems pretty random.

BTW, is the corruption not happening with GL ES because the blur effect isn't available? (I've read about that somewhere, it's pretty old though)
Comment 32 AnAkkk 2014-02-15 12:49:10 UTC
This time it got stuck again, but the messages you wanted showed up anyway:

KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 24 ): 0x "137"
KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 32 ): 0x "73"
KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x "73"

And I keep getting PostPaint GL_INVALID_OPERATION errors when I try to do anything.
(what I mean by stuck: the display works, I can move the mouse, but clicking on anything just has no effect at all, it looks like one same frame is displayed all the time, the first one after kwin's start)
Comment 33 Thomas Lübking 2014-02-15 15:24:15 UTC
(In reply to comment #31)
> BTW, is the corruption not happening with GL ES because the blur effect
> isn't available?
The glsl 1.4 blur effect shader is invalid, yes - not sure at hand whether that also applies to the logout blur shader.

(In reply to comment #32)
> This time it got stuck again, but the messages you wanted showed up anyway:
> 
> KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 24 ): 0x "137"
> KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth 32 ): 0x "73"
> KWin::GlxBackend::initBuffer: Buffer visual (depth 24 ): 0x "73"

Ok, that's certainly not good.
The same (32bit) visual (0x073) is used for the drawable and fbo and 0x137 is
0x137 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
What should not be the case since the alpha channel has 8 bits, the caveats is "slow" ...


Can you try:
-            if (samples > minSamples)
+            if (samples >= minSamples)
-            if (sampleBuffers > minSampleBuffers)
+            if (sampleBuffers >= minSampleBuffers)

in each occasion of the patch (do you need an updated patch or can you edit the present code in that regard?)
Comment 34 AnAkkk 2014-02-15 15:53:28 UTC
Now:

kwin(711) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
kwin(711): Could not find a framebuffer configuration for depth 32. 
kwin(711) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering failed:  "Could not initialize the drawable configs" 
QObject::connect: Cannot connect (null)::resetCompositing() to KWin::Compositor::restart()
kwin(711): Failed to initialize compositing, compositing disabled 
kwin(711): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up
Comment 35 Thomas Lübking 2014-02-15 16:11:03 UTC
Created attachment 85166 [details]
msaa patch

GNAGNAGNAIMSTUPIDGNAGNAGNA.

Try the latest patch and don't dare to look at it exposing my stupidity.
Comment 36 AnAkkk 2014-02-15 16:21:02 UTC
Now it works, and the corruption seem to be fixed :)

kwin(770) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
kwin(770) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth  24 ): 0x "153"
kwin(770) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth  32 ): 0x "73"
kwin(770) KWin::GlxBackend::initBuffer: Buffer visual (depth  24 ): 0x "1ae"
Comment 37 Thomas Lübking 2014-02-15 16:26:56 UTC
Ok
Many thanks for your patience =)
Comment 38 AnAkkk 2014-02-15 16:40:14 UTC
Thanks you for fixing it :)
Comment 39 Thomas Lübking 2014-02-15 19:45:25 UTC
Created attachment 85169 [details]
msaa patch, printing visuals

Fredrik says, the configs should arrive with min. samples first, so this would be a MESA/nouveau bug.

Can you apply the new patch (the one that worked + some debug printout), run it and post the two number rows it prints?
Comment 40 AnAkkk 2014-02-15 23:59:55 UTC
kwin(667) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
("153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153", "153") 
kwin(667) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth  24 ): 0x "153"
kwin(667) KWin::GlxBackend::initDrawableConfigs: Drawable visual (depth  32 ): 0x "73"
("168", "16b", "169", "16c", "16a", "16d", "1ae", "1b0", "1c1", "1c4", "1c2", "1c5", "1c3", "1c6", "15b", "15d", "171", "174", "172", "175", "173", "176", "1b4", "1b6", "1ca", "1cd", "1cb", "1ce", "1cc", "1cf", "161", "163", "17a", "17d", "17b", "17e", "17c", "17f", "1ba", "1bc", "1d3", "1d6", "1d4", "1d7", "1d5", "1d8", "12c", "182", "184", "194", "197", "195", "198", "196", "199", "130", "132", "188", "18a", "19d", "1a0", "19e", "1a1", "19f", "1a2", "21", "14d", "150", "14e", "14f", "152", "22", "18f", "1a6", "1a9", "1a7", "1aa", "1a8", "1ab", "151", "12a", "157", "13f", "155", "144", "146", "147", "13e", "148", "73", "140", "13b", "13c", "145", "149", "13d") 
kwin(667) KWin::GlxBackend::initBuffer: Buffer visual (depth  24 ): 0x "1ae"
Comment 41 Thomas Lübking 2014-02-16 00:43:55 UTC
D'hoo  - the 153 collection is the good old copy & paste bug (i->j) again...
It's luckily not relevant =)
---

Ok, many thanks.

It seems to prefer TrueColor over DirectColor (that's expected) over sample count sorting (may be intended), but even then 0x157 should apparently take precedence:

0x153 24 tc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x157 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x1ae 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None

So given the sample count sorting is still supposed, there's a bug in either nouveau or MESA, it appears the double buffer support is ignored when sorting the list (so that 0x153 and 0x157 are assumed equal, 0x153 moved to front and 0x157 ignored from sorting) - but that's sth. for the MESA devs to say =)
Comment 42 AnAkkk 2014-02-16 00:55:34 UTC
Might be interesting as well:
https://git.reviewboard.kde.org/r/115762/
Comment 43 AnAkkk 2014-02-16 00:55:54 UTC
Oops, posted that at the wrong place, sorry.
Comment 44 AnAkkk 2014-02-16 00:56:41 UTC
I reopened my bug report on freedesktop:
https://bugs.freedesktop.org/show_bug.cgi?id=74316