Bug 325610 - ShowFPS effect leaks a texture, causing the static fbo for clearing to dangle
Summary: ShowFPS effect leaks a texture, causing the static fbo for clearing to dangle
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: effects-various (show other bugs)
Version: 4.11.2
Platform: Archlinux Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/113...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-04 03:41 UTC by Gerardo Exequiel Pozzi
Modified: 2013-10-20 18:02 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.11.3
thomas.luebking: ReviewRequest+


Attachments
Window corruption when opening queue window in HandBrake (240.20 KB, image/jpeg)
2013-10-05 18:30 UTC, Gerardo Exequiel Pozzi
Details
window outside borders on move (406.37 KB, image/jpeg)
2013-10-05 19:10 UTC, Gerardo Exequiel Pozzi
Details
qdbus org.kde.kwin /KWin supportInformation (5.60 KB, text/plain)
2013-10-06 18:35 UTC, Gerardo Exequiel Pozzi
Details
qdbus org.kde.KWin /Compositor resume #Normal behaviour (3.22 KB, text/plain)
2013-10-06 18:36 UTC, Gerardo Exequiel Pozzi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerardo Exequiel Pozzi 2013-10-04 03:41:38 UTC
This happens since commit da78b49a3698a3a11ea1c68e3b5af3cecd5c00d5 (introduce GLTexture::clear and use it from paintredirector), reverting it on kdebase-workspace fixes the issue. I am using nvidia card (GT520) with binary-blobs drivers (319.23).

This only happens after cycle off/on desktop effect that I need to do because of the vsync not enabled on login on nvidia (Bug 322060)

I experiment window corruption on borders (multicolored trash) when opening, and disappears after moving it.
Also a temporal but different corruption happens during window movement, like a small parallel vertical line on top-right corner, and parallel horizontal line on bottom-left.


Reproducible: Always

Steps to Reproduce:
1. Disable desktop effects.
2. Enable desktop effects.
3. Open Handbrake with some enqueue file.
4. Say "Yes" to reload pending files.
5. A new window appears with big borders corrupted..
6. Open a window of any program and move it, observe top-right and bottom-left corners for a parallel multicolored line moving with window.
Actual Results:  
Decorators corruption.

Looking on errors, I can see this message on window opening:
kwin(1858) KWin::checkGLError: GL error ( update texture ):  "GL_INVALID_OPERATION"


Kwin settings:

Compositing Type: OpenGL 3.1 (also with 2.0)
QT Graphics: Raster
Thumbnails: 'Only shown for Windows'
Scale Method: Accurate
Suspend desktop effects for fullscreen windows: unchecked/disabled
Tearing Prevention: Automatic
Colour correction: Disabled
Comment 1 Thomas Lübking 2013-10-04 09:45:04 UTC
> This only happens after cycle off/on desktop effect that I need to do because of the vsync not 
> enabled on login on nvidia (Bug 322060)

Interesting detail, but should no longer be required (triple buffer detection should be fixed, please compare the ouput of
            qdbus org.kde.kwin /KWin supportInformation | grep -i block

On bug:

- Does it also happen if you restart "kwin --replace &" at runtime?
- Can you provide a screenshot?
- Can you check whether you enter
    if (--s_textureObjectCounter == 0 && s_fbo) {
        glDeleteFramebuffers(1, &s_fbo);
        s_fbo = 0;
    }

in GLTexturePrivate::~GLTexturePrivate() in libkwineffects/kwingltexture.cpp when suspending the compositor?
Comment 2 Gerardo Exequiel Pozzi 2013-10-05 18:30:30 UTC
Created attachment 82678 [details]
Window corruption when opening queue window in HandBrake
Comment 3 Gerardo Exequiel Pozzi 2013-10-05 18:35:41 UTC
(In reply to comment #1)
> > This only happens after cycle off/on desktop effect that I need to do because of the vsync not 
> > enabled on login on nvidia (Bug 322060)
> 
> Interesting detail, but should no longer be required (triple buffer
> detection should be fixed, please compare the ouput of
>             qdbus org.kde.kwin /KWin supportInformation | grep -i block

This is the output at first login time (kwin4_effect_showfps shows ~94 fps should be at 60):
Painting blocks for vertical retrace:  yes

> 
> On bug:
> 
> - Does it also happen if you restart "kwin --replace &" at runtime?

No, it does not happens (kwin4_effect_showfps shows ~94 fps should be at 60):
Painting blocks for vertical retrace:  no


> - Can you provide a screenshot?
$ qdbus org.kde.KWin /Compositor suspend
$ qdbus org.kde.KWin /Compositor resume

Yes, attached. Only for the fixed case on window opening from Handbrake. For window movement, screenshot with timeout does not capture the bug.

> - Can you check whether you enter
>     if (--s_textureObjectCounter == 0 && s_fbo) {
>         glDeleteFramebuffers(1, &s_fbo);
>         s_fbo = 0;
>     }
> 
> in GLTexturePrivate::~GLTexturePrivate() in libkwineffects/kwingltexture.cpp
> when suspending the compositor?

How I can do this? recompiling with some flag?

The only messages I see on suspend are:
kwin(9395) KWin::EffectsHandlerImpl::unloadEffect: EffectsHandler::unloadEffect : Unloading Effect :  "kwin4_effect_magnifier"
<above-msg-for-each-loaded-effect>
kwin(9395) KWin::Compositor::releaseCompositorSelection: Releasing compositor selection
Comment 4 Gerardo Exequiel Pozzi 2013-10-05 19:10:52 UTC
Created attachment 82680 [details]
window outside borders on move
Comment 5 Thomas Lübking 2013-10-05 22:58:36 UTC
(In reply to comment #3)

> This is the output at first login time (kwin4_effect_showfps shows ~94 fps
> should be at 60):

Please attach the entire output of "qdbus org.kde.kwin /KWin supportInformation" and the output of "xrandr -q". You're not syncing not run a 100Hz screen.

----

> > - Does it also happen if you restart "kwin --replace &" at runtime?
> 
> No, it does not happens
I meant the glitches/artifacts/garbaged textures

 (kwin4_effect_showfps shows ~94 fps should be at 60):

> Yes, attached. Only for the fixed case on window opening from Handbrake.

The second screenshot indicates that the texture isn't cleared (the issue that clearing orignally fixed) the first one is however confusing:
It seems the "Handbrake" window would be above the "Handbrake Queue" window and by this the corruption would be either in the framebuffer or in the window texture, not the decoration texture?

- Does this also happen if you set the tearing prevention to "full repaints"?
- Is running Handbrake mandatory to cause the corruption?

> How I can do this? recompiling with some flag?

Either set a breakpoint and run kwin in gdb (from VT1) or inject a line

if (--s_textureObjectCounter == 0 && s_fbo) {
   qDebug() << "------------- Deleting s_fbo";
   glDeleteFramebuffers(1, &s_fbo);
   s_fbo = 0;
}

Latter is simpler ;-)
Comment 6 Gerardo Exequiel Pozzi 2013-10-06 18:34:11 UTC
(In reply to comment #5)
> (In reply to comment #3)
> 
> > This is the output at first login time (kwin4_effect_showfps shows ~94 fps
> > should be at 60):
> 
> Please attach the entire output of "qdbus org.kde.kwin /KWin
> supportInformation" and the output of "xrandr -q". You're not syncing not
> run a 100Hz screen.

xrandr :    1920x1200      60.0*+   59.9

Offtopic: I now workaround the fps vs hz issue so fps is always at 60fps (TripleBuffer On + KWIN_TRIPLE_BUFFER=1 since autodetection fails sometimes). Anyway I can still reproduce the corruption...

> 
> ----
> 
> > > - Does it also happen if you restart "kwin --replace &" at runtime?
> > 
> > No, it does not happens
> I meant the glitches/artifacts/garbaged textures

Nothing. No corruptions during restarting kwin. Indeed restating kwin fixes the issue until I do again a cycle of suspend/resume composition.

> 
>  (kwin4_effect_showfps shows ~94 fps should be at 60):
> 
> > Yes, attached. Only for the fixed case on window opening from Handbrake.
> 
> The second screenshot indicates that the texture isn't cleared (the issue
> that clearing orignally fixed) the first one is however confusing:
> It seems the "Handbrake" window would be above the "Handbrake Queue" window
> and by this the corruption would be either in the framebuffer or in the
> window texture, not the decoration texture?
> 

I am not expert here. How to know about this?

> - Does this also happen if you set the tearing prevention to "full repaints"?

Yes.

> - Is running Handbrake mandatory to cause the corruption?

Yes for corruption.
but the message "kwin(17471) KWin::checkGLError: GL error ( update texture ): "GL_INVALID_OPERATION" appears for any new window opened (no corruption).

> 
> > How I can do this? recompiling with some flag?
> 
> Either set a breakpoint and run kwin in gdb (from VT1) or inject a line
> 
> if (--s_textureObjectCounter == 0 && s_fbo) {
>    qDebug() << "------------- Deleting s_fbo";
>    glDeleteFramebuffers(1, &s_fbo);
>    s_fbo = 0;
> }
> 
> Latter is simpler ;-)

OK. Recompiled with gDebug()...
1) Nothing shows in kwin output when suspend compositor for first time on login.
2) If I restart kwin (kwin --replace& @ Konsole), then suspend compositor again, message appears.  I can suspend/resume again and again... and message appears. In this case there is no corruption or message about GL_INVALID_OPERATION on any window opening.
3) Doing some tests, trying to make kwin fails in case (2), I found at least one way.
a) kwin --replace &
b) qdbus org.kde.KWin /Effects loadEffect kwin4_effect_showfps
c) qdbus org.kde.KWin /Effects unloadEffect kwin4_effect_showfps
d) qdbus org.kde.KWin /Compositor suspend
e) qdbus org.kde.KWin /Compositor resume

(c) Is optional with or without this kwin fails (no Deleting) on suspend.
(d) The only message after all effects are unloaded is: "kwin(27477) KWin::Compositor::releaseCompositorSelection: Releasing compositor selection"
(e) Apart of normal messages (attached) kwin shows this: kwin(27477) KWin::checkGLError: GL error ( PostPaint ):  "GL_INVALID_OPERATION"

The only way to fix kwin again is reexecuting it.
Comment 7 Gerardo Exequiel Pozzi 2013-10-06 18:35:38 UTC
Created attachment 82693 [details]
qdbus org.kde.kwin /KWin supportInformation
Comment 8 Gerardo Exequiel Pozzi 2013-10-06 18:36:43 UTC
Created attachment 82694 [details]
qdbus org.kde.KWin /Compositor resume #Normal behaviour
Comment 9 Thomas Lübking 2013-10-06 20:45:36 UTC
(In reply to comment #6)

> Offtopic: I now workaround the fps vs hz issue so fps is always at 60fps
Ok, still the effects should not run > 60Hz given your setup (on 4.11.2, on 4.11.1 - could very much be possible)
Also the autodetection should no longer fail in this version (and didn't for the attached supportInformation)
~/.xsession-errors should contain information about the detection (whether and by how many ms delay of buffer swapping it failed) and whether syncing is turned off for it.

> 3) Doing some tests, trying to make kwin fails in case (2), I found at least
> one way.

Thanks alot. The showfps effect leaks a texture, i can see it -> gonna add a patch.

This also pretty much explains it - if the fbo isn't freed/recreated it will end up being invalid, getting you a GL error and no texture clearing. Operating on the invalid fbo can then very well cause graphical corruption.

Do you start the showfps effect with the session? (It's been my testcase for the wrong TB detection, for it caused that for sure, but no more after the last patch on bug #322060 was applied)
Comment 10 Thomas Lübking 2013-10-06 20:59:52 UTC
patch:
https://git.reviewboard.kde.org/r/113136/diff/raw/
Comment 11 Gerardo Exequiel Pozzi 2013-10-06 21:21:45 UTC
(In reply to comment #9)
> (In reply to comment #6)
> 
> > Offtopic: I now workaround the fps vs hz issue so fps is always at 60fps
> Ok, still the effects should not run > 60Hz given your setup (on 4.11.2, on
> 4.11.1 - could very much be possible)
> Also the autodetection should no longer fail in this version (and didn't for
> the attached supportInformation)
> ~/.xsession-errors should contain information about the detection (whether
> and by how many ms delay of buffer swapping it failed) and whether syncing
> is turned off for it.
> 

You are right, maybe during many test I made, I was something mixed thing. Always start ok without forcing.

> > 3) Doing some tests, trying to make kwin fails in case (2), I found at least
> > one way.
> 
> Thanks alot. The showfps effect leaks a texture, i can see it -> gonna add a
> patch.
> 
> This also pretty much explains it - if the fbo isn't freed/recreated it will
> end up being invalid, getting you a GL error and no texture clearing.
> Operating on the invalid fbo can then very well cause graphical corruption.
> 
> Do you start the showfps effect with the session? (It's been my testcase for
> the wrong TB detection, for it caused that for sure, but no more after the
> last patch on bug #322060 was applied)

Nice!. During tests was started manually sometimes and other automatically. (I used it to qucikly know the right fps, when I did not have triple buffer enabled) Definitively, it was the problem. I am going to test patch now. Thanks you!
Comment 12 Gerardo Exequiel Pozzi 2013-10-06 22:01:41 UTC
Perfectly. Works now really good. Thanks.
Comment 13 Thomas Lübking 2013-10-06 22:35:26 UTC
See? It's not a regression, but a very sophisticated leak detection system ;-)
Comment 14 Gerardo Exequiel Pozzi 2013-10-06 23:31:26 UTC
(In reply to comment #13)
> See? It's not a regression, but a very sophisticated leak detection system
> ;-)

Hehehe. Absolutelly. Good work ;)
Comment 15 Thomas Lübking 2013-10-20 18:02:28 UTC
Git commit aed179611d5d51264c79159311385cf5bfedd1c4 by Thomas Lübking.
Committed on 06/10/2013 at 20:58.
Pushed by luebking into branch 'KDE/4.11'.

don't leak fpstext texture
FIXED-IN: 4.11.3
REVIEW: 113136

M  +1    -3    kwin/effects/showfps/showfps.cpp
M  +1    -1    kwin/effects/showfps/showfps.h

http://commits.kde.org/kde-workspace/aed179611d5d51264c79159311385cf5bfedd1c4