Bug 323065 - In KDE 4.11RC2, KWin has bad rendering when using the AMD Catalyst drivers
Summary: In KDE 4.11RC2, KWin has bad rendering when using the AMD Catalyst drivers
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (show other bugs)
Version: 4.10.95
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/112...
Keywords:
: 323792 323806 324338 324755 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-07-31 21:57 UTC by Joe
Modified: 2013-10-03 06:25 UTC (History)
11 users (show)

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


Attachments
kwin support info (5.40 KB, text/plain)
2013-07-31 23:33 UTC, Joe
Details
Screenshot1 (3.07 MB, image/png)
2013-07-31 23:38 UTC, Joe
Details
Screen shot demonstatring beta driver issue (3.06 MB, image/png)
2013-07-31 23:41 UTC, Joe
Details
Bad repaint (what the beta drivers look like) after changing (277.78 KB, image/png)
2013-08-01 14:55 UTC, Joe
Details
replacing kwin log (8.00 KB, text/plain)
2013-08-01 14:56 UTC, Joe
Details
ps -aux | grep kwin (134 bytes, text/plain)
2013-08-01 14:58 UTC, Joe
Details
Catalyst 13.8 Beta (235.06 KB, image/png)
2013-08-06 15:37 UTC, Joe
Details
my Xorg.0.log and kwin debug output (12.73 KB, application/x-gzip)
2013-08-22 15:59 UTC, S. Christian Collins
Details
Preserve pot. previous FBO and yell a warning if we had it overridden (810 bytes, patch)
2013-09-01 21:30 UTC, Thomas Lübking
Details
clear the texture the legacy way (1.35 KB, patch)
2013-09-04 11:00 UTC, Thomas Lübking
Details
slightly modified variant (1.68 KB, patch)
2013-09-04 17:27 UTC, Thomas Lübking
Details
alternative approach, NOT USABLE AS FINAL PATCH (1.09 KB, patch)
2013-09-05 19:18 UTC, Thomas Lübking
Details
kwin segfault opening Skype (4.42 KB, text/plain)
2013-09-09 19:51 UTC, S. Christian Collins
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joe 2013-07-31 21:57:33 UTC
There are quite a few glitches I have noticed  in RC2 while using the Catalyst drivers (Dell M4600, Radeon HD 6730M/6770M/7690M XT). There is a lot of graphical corruption on login (blank screen, partially drawn windows with no decorations), and after  a second the background is rendered and the window borders are drawn. While this is pretty minor, the bigger issue I have seen so far is if you take a fullscreen window and click on it to restore it, when it is restored on the latest stable drivers, the shadows on the sides of the windows are no longer drawn until the window is resized/redrawn. On the latest beta drivers the same thing happens, but the top right and left corners disappear  (including the buttons), too.

Reproducible: Always

Steps to Reproduce:
1. Open Dolphin
2. Maximize the window (double click the title bar or the button)
3. Restore the window (double click the  title bar or the button)

Actual Results:  
On the stable release of Catalyst, the window border/shadow is not  drawn on the sides of the screen. On the latest beta driver release, the top right & left corners are also not drawn. This is fixed by resizing the window (or changing a tab if the program has tab support). Dragging the window has no effect.

Expected Results:  
On either driver, the maximize and restore should work without rendering glitches.

I am using the stock KDE 4.11rc2 settings on a clean install of KDE (I removed my old .kde directory from 4.10). For stable, I am using Catalyst 13.4, and the beta driver is 13.7 (or 15). On stable, I am running its latest supported XOrg server, and on beta I am using the actual latest release (as it now supports it). Lastly, my kernel is 3.10.4.

KWin Settings:

Compositing Type: OpenGL 2.0
QT Graphics: Raster
Thumbnails: 'Only shown for Windows'
Scale Method: Accurate
Suspend desktop effects for fullscreen windows: checked/enabled
Tearing Prevention: Automatic
Colour correction: Disabled
Comment 1 Thomas Lübking 2013-07-31 22:19:34 UTC
please attach the output of "qdbus org.kde.kwin /KWin supportInformation"
Comment 2 Joe 2013-07-31 23:33:28 UTC
Created attachment 81494 [details]
kwin support info

output of qdbus-qt4 org.kde.kwin /KWin supportInformation > kwinSupportInfo.txt
Comment 3 Joe 2013-07-31 23:38:46 UTC
Created attachment 81495 [details]
Screenshot1

Screenshot of the issue on the latest stable driver. Note that  taking the screen shot actually fixes it (although it shows up in the screen shot).
Comment 4 Joe 2013-07-31 23:41:56 UTC
Created attachment 81496 [details]
Screen shot demonstatring beta driver issue

Mock up on what happens in the latest beta drivers. The same on the side thing happens, but the corners also disappear (red boxes to demonstrate). Hovering over the missing corners will make the buttons visible  again, but there are transparent lines around them (i.e. only the  buttons are shown, the rest of the corner/background remains transparent). To get it fully rendered properly, the window needs to be either  resized, minimized, or something like switching tabs in it.
Comment 5 Joe 2013-07-31 23:42:36 UTC
OK, I attached that plus 2 screen shots demonstrating the problem (note the second one is what happens on the Beta drivers - I no longer have them installed, so I just kind of mocked it up).
Comment 6 Thomas Lübking 2013-08-01 10:57:39 UTC
Things to try:

1. use the native graphicssystem
2. disable the "maximize" effect
3. disable the blur effect
(all  in "kcmshell4 kwincompositing")
4. run
   kwriteconfig --file kwinrc --group Compositing --key GLStrictBinding false
   qdbus org.kde.kwin /KWin reconfigure
   qdbus org.kde.kwin /KWin reconfigure
   qdbus org.kde.kwin /Compositor suspend
   qdbus org.kde.kwin /Compositor resume

Does any of this have any impact?

If not, run "kdebugdialog", activate "1212 (KWin)" and run "kwin --replace &"
Are there any  GL error messages when unmaximizing windows?

About the login corruption: does eventually kwin crash on login (is there any Dr. Konqui crash dialog?
If not, what's the output of "ps ax | grep kwin"?
Does it say anything like "/usr/bin/kwin --crashes 1"?
Comment 7 Joe 2013-08-01 14:55:35 UTC
Created attachment 81505 [details]
Bad repaint (what the beta drivers look like) after changing

When enabling/disabling effects (latest stable catalyst), this happens, which is exactly what was happening all the time (when maximizing/restoring windows) in the Beta drivers.
Comment 8 Joe 2013-08-01 14:56:59 UTC
Created attachment 81506 [details]
replacing kwin log

Attached is the terminal output when running the kwin replace command.
Comment 9 Joe 2013-08-01 14:58:03 UTC
Created attachment 81507 [details]
ps -aux | grep kwin

Attaching output of ps -aux | grep kwin
Comment 10 Joe 2013-08-01 15:05:42 UTC
OK, nothing really worked:

1) Had no effect
2) & 3) See my new screen shot - it had  no effect and caused the issue I said the Beta drivers had
4) This didn't help anything (in fact it kind of broke my desktop, I had to nuke my .kde4 directory, were the second and third commands supposed to be the same?)

So no (or worse impact) for those.

5) "kwin --replace &" - I attached the output from the terminal, as far as I can see/tell there were no errors

I played  around with it a bit, and changing  the compositor to XRender from OpenGL2.0 actually solves the problem. However, XRender is much slower.

Startup problem:

6) On startup, there  are no errors/crashes. I attached the output of 'ps -aux |grep kwin'. It is kind  of odd - like I said its a black desktop, then the remembered  windows popup (in the wrong place/size), this it kind of things for a  second, pops all of the windows to where they should be, kind of pauses  again, adds in the taskbar and the window decorations, and then finally the background. The entire process doesn't take too long, it just looks odd compared to say KDE 4.10.
Comment 11 Thomas Lübking 2013-08-04 19:51:37 UTC
(In reply to comment #10)
> 4) This didn't help anything (in fact it kind of broke my desktop, I had to
> nuke my .kde4 directory, were the second and third commands supposed to be the same?)

Sorry for that - i forgot that this could break GL compositing.
Resetting the value (or deleting the key) would have done - in doubt ever just delete ~/.kde4/share/config/kwinrc - no need to nuke everything.

One of them is just a copy and paste leftover (has no effect though)

> I played  around with it a bit, and changing  the compositor to XRender from OpenGL2.0 actually solves the problem.

Not much of a surprise.
For some reason mapping the updated decoration images into textures does not happen (in time)

Question is why and why on this occasion.

Last wild shot:
run "oxygen-settings", select "Window Decorations" and in the "Aniamtions" tab, just deactivate animations.
Restart kwin to be on the safe side and see what happens. (This does for sure not severely break things ;-)

> However, XRender is much slower.
Driver (fglrx) issue (for sure: already ATi had a record here and unrelated to KWin or KDE)

> 6) 
> the remembered  windows popup (in the wrong place/size), this it kind of
> things for a  second, pops all of the windows to where they should be, kind
> of pauses  again, adds in the taskbar and the window decorations, and then


Ahhh ... plasma panel containment strut updating fun.
Set all panels to "window can cover" - funky animation gone?
Comment 12 Joe 2013-08-06 15:29:36 UTC
OK, so I tried disabling the animations per your instructions, but it had little/no effect. Also, I attached an odd screen shot I got on the newest beta driver (13.8). But yeah, I would give anything to go back to my old laptop with Intel graphics at this point, Catalyst is a pretty 'special' driver.

On the brighter side - enabling 'window can cover' on the taskbar did in fact clear up most of my funking login stuff, its just too bad I can't have it enabled all the time, heh.
Comment 13 Joe 2013-08-06 15:37:23 UTC
Created attachment 81588 [details]
Catalyst 13.8 Beta

With the latest beta, you can get it so the button corners actually show up in the wrong window's corners.
Comment 14 Joe 2013-08-12 20:19:35 UTC
Any updates on this? Not sure if there will be an RC3 or not, but it seems like a pretty good bug, heh.
Comment 15 Thomas Lübking 2013-08-13 19:20:00 UTC
No, but i'm not sure whether any developer is using fglrx.

- You could first try to disable all effect plugins (ie. zoom, fade etc.) but keep compositing enabled.

- Second a different decoration (try "laptop" and "plastik")

- And third indirect rendering:
   KWIN_DIRECT_GL=0 LIBGL_ALWAYS_INDIRECT=1 kwin --replace &
(temporary, so even if it breaks, it's gone with the next login latest)
Comment 16 Joe 2013-08-14 17:11:56 UTC
OK, so disabling the effects had no effect (anyway to easily restore the default ones?). Plastik actually kind of works better - it doesn't mess up rendering  as often (although full screening a window seems to  cause half of the title bar to disappear from time to time). The laptop theme was probably more broken that Oxygen. Lastly, I tried the indirect rendering with KWin. This seemed to correct the glitches in the window decoration, however, everything overall was pretty janky, so I had reverted.

And yeah, really wish I had my ol' Intel integrated graphics back, heh. I will note though, that these issues were not present in  4.10, if that helps anything.
Comment 17 Thomas Lübking 2013-08-15 02:29:19 UTC
(In reply to comment #16)
> anyway to easily restore the default ones?
delete the kwin4_* entries in the [Plugins] section of ~/.kde/share/config/kwinrc

> The laptop theme was probably more broken that Oxygen.
It has probably unrelated issues due on the raster graphicssystem. Does it displace/drop elements as well (on the native graphicssystem)?

> Lastly, I tried the indirect rendering with KWin.
> This seemed to correct the glitches in the window decoration,
> however, everything overall was pretty janky, so I had reverted.

Does setting the tearing prevention to "full scene repaints" change anything?
Comment 18 Joe 2013-08-15 15:39:52 UTC
> delete the kwin4_* entries in the [Plugins] section of
> ~/.kde/share/config/kwinrc

Thanks - maybe I should put a feature request in for this to be in the GUI, lol.
 
> > The laptop theme was probably more broken that Oxygen.
> It has probably unrelated issues due on the raster graphicssystem. Does it
> displace/drop elements as well (on the native graphicssystem)?

Native had no effect.

> > Lastly, I tried the indirect rendering with KWin.
> > This seemed to correct the glitches in the window decoration,
> > however, everything overall was pretty janky, so I had reverted.
> 
> Does setting the tearing prevention to "full scene repaints" change anything?
I tried this and it didn't do anything (also tried setting Catalyst's tearing prevention on and off, which did nothing)
Comment 19 Thomas Lübking 2013-08-15 16:59:49 UTC
(In reply to comment #18)
Do you compile KWin yourself (so you could revert patches)?

Atm. i'd say fglrx has issues with the texture atlas commit:
https://git.reviewboard.kde.org/r/110790/
http://commits.kde.org/kde-workspace/15d1bc6b4dbdd397c715a4036f30d58c2760357f

But it's really just a wild guess :-(
Comment 20 Joe 2013-08-15 17:02:36 UTC
I probably could - right now I am on Arch's stable 4.11.0 release.
Comment 21 Thomas Lübking 2013-08-20 21:21:16 UTC
*** Bug 323806 has been marked as a duplicate of this bug. ***
Comment 22 Joe 2013-08-21 15:01:33 UTC
Hey, sorry, have been rather busy traveling - is there a good tutorial or something for building KWin, and I could give it a shot.
Comment 23 S. Christian Collins 2013-08-21 21:36:02 UTC
If I knew how to undo the texture atlas commit, I would try compiling kwin without it. As it stands, there are enough other differences in the files between then and now, that I don't think I could manually undo the commit without messing something up. Unfortunately, I don't really know C++.

That being said, if there's a way for me to test this on Kubuntu 12.04 (using KDE 4.11 from Kubuntu PPA), I would be happy to do so.
Comment 24 Thomas Lübking 2013-08-22 10:19:00 UTC
(In reply to comment #23)
> If I knew how to undo the texture atlas commit, I would try compiling kwin
> without it.

That's no more trivially possible, you'd actually have to bisect to figure the breaking commit.

However, from observations in bug #323792 i wonder whether this is due to the effective ARGB state of the decoration.

You could quickly test whether (globally, Alt+MouseWheel) translucent windows (resp. an aurorae theme) are also affected for you (what would also match Joes observations on Plastik, while Laptop is always opaque)
Comment 25 Thomas Lübking 2013-08-22 10:19:24 UTC
*** Bug 323792 has been marked as a duplicate of this bug. ***
Comment 26 Joe 2013-08-22 14:57:48 UTC
Hey, I tried the 'alt' + mouse wheel and it doesn't really appear to do anything. And remember, while better, Plastik still had some issues and Laptop was worse...
Comment 27 S. Christian Collins 2013-08-22 15:59:46 UTC
Created attachment 81856 [details]
my Xorg.0.log and kwin debug output

Well, now I've run into a whole other issue. After reinstalling the fglrx driver (I had been using the open-source driver after encountering this bug), kwin will no longer allow me to enable OpenGL compositing (any version). Looking at the kwin debug output, I get this:
--------
OpenGL vendor string:                   ATI Technologies Inc.
OpenGL renderer string:                 AMD Radeon HD 7660G
OpenGL version string:                  2.1 (4.2.12217 Compatibility Profile Context 12.104)
OpenGL shading language version string: 
Driver:                                 Catalyst
Driver version:                         2.1
GPU class:                              Unknown
OpenGL version:                         2.1
GLSL version:                           0.0
X server version:                       1.12.3
Linux kernel version:                   3.5
Direct rendering:                       no
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
kwin(2742) KWin::GlxBackend::init: Direct rendering: false
kwin(2742) KWin::checkGLError: GL error ( Init ):  "GL_INVALID_ENUM" 
kwin(2742): OpenGL 1 compositing setup failed 
QObject::connect: Cannot connect (null)::resetCompositing() to KWin::Compositor::restart()
kwin(2742): Failed to initialize compositing, compositing disabled 
kwin(2742): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up
--------

Kwin reports direct rendering as "no", but running "glxinfo | grep direct" reports this:
--------
direct rendering: Yes
    GL_AMD_draw_buffers_blend, GL_AMD_multi_draw_indirect, 
    GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect, 
    GL_ARB_map_buffer_range, GL_ARB_multi_draw_indirect, GL_ARB_multisample, 
    GL_EXT_copy_buffer, GL_EXT_copy_texture, GL_EXT_direct_state_access, 
    GL_AMD_draw_buffers_blend, GL_AMD_multi_draw_indirect, 
    GL_ARB_draw_indirect, GL_ARB_draw_instanced, 
    GL_ARB_map_buffer_range, GL_ARB_multi_draw_indirect, GL_ARB_multisample, 
    GL_EXT_copy_buffer, GL_EXT_copy_texture, GL_EXT_direct_state_access,
--------

...and OpenGL apps and games seem to work fine and at full rendering speed. The attachment contains my Xorg.0.log and full kwin debug output.
Comment 28 S. Christian Collins 2013-08-22 16:12:38 UTC
Setting the environment variable KWIN_DIRECT_GL=1 allowed me to use OpenGL compositing again. I used the mouse wheel over the titlebar to change the window transparency, but this didn't seem to have any effect on this bug.

I've followed instructions to do a bisect on Wine before. I'd be willing to try for Kwin, but I will just need some good instructions to follow. My only experience compiling KDE components so far is using the Kubuntu source packages.
Comment 29 Thomas Lübking 2013-08-22 18:03:13 UTC
(In reply to comment #27)

> Well, now I've run into a whole other issue. After reinstalling the fglrx
> driver (I had been using the open-source driver after encountering this
> bug), kwin will no longer allow me to enable OpenGL compositing (any
> version). Looking at the kwin debug output, I get this:

This is bug #323553

Question:
Did fglrx run before with 4.11 or 4.10.5 only?

Reg. bisecting,

git clone git://anongit.kde.org/kde-workspace.git
cd kde-workspace
git checkout KDE/4.11
mkdir build
cd build
ccmake ..
[press "c", adjust installation paths - you can probably just override the present installation, what to build (kwin), build options (don't build the oxygen deco, could lead to trouble with broken ABI, press "c" again, then "g", then "q"]
cd kwin
make && sudo make install

-> if that worked, you are in position to start a bisect.
git assists you with the "git bisect" command:

   git bisect start
   git bisect good origin/KDE/4.10
   git bisect bad origin/KDE/4.11

next you recompile, install, restart kwin and see whether the bug is still there. In that cas you do

   git bisect bad

otherwise

   git bisect good

At some point git bisect will tell you the cuplrit commit (which you may post here)

Afterwards call

   git bisect reset

and you're done =)
It's gonna take some more time though (but it's of course "bisect", because you perform a binary search, ie. you won't test every commit but narrow the good/bad frame)
Comment 30 Thomas Lübking 2013-08-22 18:39:12 UTC
(In reply to comment #26)
> Hey, I tried the 'alt' + mouse wheel and it doesn't really appear to do
> anything.

The behavior can be configured in "kcmshell4 kwinoptions", "window actions" tab, lower group.

> And remember, while better, Plastik still had some issues
Yes, but as I understood they were not exactly the same type?
(Maybe also try some Aurorae theme, ie. what you get via "Get New Decorations")

> and Laptop was worse...
Laptop is never effectively ARGB (unlike Oxygen, which has rounded corners on non-maximized windows), so this actually stresses the pattern.
Comment 31 Thomas Lübking 2013-08-22 18:41:09 UTC
(In reply to comment #28)
> compositing again. I used the mouse wheel over the titlebar to change the
> window transparency, but this didn't seem to have any effect on this bug.

Forgot:
this could imply it would really depend on the texture depth and not the render path.
Did you check Aurorae themes or Plastik?
Comment 32 S. Christian Collins 2013-08-22 22:16:19 UTC
(In reply to comment #29) 
> Question:
> Did fglrx run before with 4.11 or 4.10.5 only?

It ran with both, but the fglrx driver version was different (I think it was 12.103). Upon reinstalling fglrx, a newer version was available (12.104) from the xorg-edgers repository, and I no longer can install 12.103. It also fails with 13.200, which I'm avoiding because it causes hard-freezes on my laptop. So, perhaps the direct rendering test fails with the newer drivers?

I'm compiling kwin right now. Assuming kwin installs and runs correctly, I should hopefully have a bisect report for you shortly.
Comment 33 Thomas Lübking 2013-08-22 22:29:08 UTC
(In reply to comment #32)
> (In reply to comment #29) 
> > Question:
> > Did fglrx run before with 4.11 or 4.10.5 only?
> 
> So, perhaps the direct rendering test fails with the newer drivers?
Either the newer (legacy?) driver does no longer work on OpenGL 1.2, you missed calling "aticonfig --initial", or AMD changed internal driver version counting (so you had > required version and now no longer)

> I'm compiling kwin right now. Assuming kwin installs and runs correctly, I
> should hopefully have a bisect report for you shortly.

Many thanks - I'll check back tomor... next week ;-)
Comment 34 S. Christian Collins 2013-08-22 23:31:49 UTC
Just FYI, I'm having to run "git bisect skip" on some of the commits (3 out of 5 so far) due to OpenGL rendering refusing to start up at all. Kwin's output for these commits:

kwin(27367) KWin::Compositor::slotCompositingOptionsInitialized: Initializing OpenGL compositing
kwin(27367): Could not find a framebuffer configuration for depth 32. 
kwin(27367) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering failed:  "Could not initialize the drawable configs" 
kwin(27367): Failed to initialize compositing, compositing disabled

I hope this doesn't interfere too much with the ability to track down the problem commit.

UPDATE: I just had to skip another due to a compile error.
Comment 35 Thomas Lübking 2013-08-23 00:26:12 UTC
(In reply to comment #34)
> Just FYI, I'm having to run "git bisect skip" on some of the commits (3 out
> of 5 so far) due to OpenGL rendering refusing to start up at all. Kwin's
> output for these commits:
> 
> kwin(27367) KWin::Compositor::slotCompositingOptionsInitialized:
> Initializing OpenGL compositing
> kwin(27367): Could not find a framebuffer configuration for depth 32. 
> kwin(27367) KWin::OpenGLBackend::setFailed: Creating the OpenGL rendering
> failed:  "Could not initialize the drawable configs" 
> kwin(27367): Failed to initialize compositing, compositing disabled

You found bug #317972 - if the problematic commit is somewhere in this range, this can be trivially fixed by patching in commit 5edf346ad8a19b6989fad7290e599824dd2414f2

I'll tell you how when this turns out a problem.
Comment 36 S. Christian Collins 2013-08-23 01:35:43 UTC
Perhaps you should show me how to do the patch. So far in the bisect, I've marked 2 good, 1 bad and 16 skips. At this rate, this process is not likely to end anytime soon.
Comment 37 S. Christian Collins 2013-08-23 04:06:30 UTC
Nevermind... I figured out how to do it myself. It's only a 1 line code change... not hard to manually edit glxbackend.cpp and then restore the original file before going on to the next bisect test. So, I started over, but I'm actually making progress now :)
Comment 38 Thomas Lübking 2013-08-23 04:33:39 UTC
(In reply to comment #37)
> Nevermind... I figured out how to do it myself.

Good to hear. Sorry for not replying - "night".
(And I'm no longer 20, so i've to sleep every now and then =)
Comment 39 S. Christian Collins 2013-08-23 04:55:03 UTC
Here you go:
--------------------------
48496454666715304e2d75c0bc396b57557c530e is the first bad commit
commit 48496454666715304e2d75c0bc396b57557c530e
Author: Fredrik Höglund <fredrik@kde.org>
Date:   Mon Mar 18 19:43:05 2013 +0100

    kwin: Clear the decoration textures after resizing
    
    This fixes artifacts from over-sampling along the edges of the
    decorations when effects such a wobbly windows are active.
    
    The textures are only cleared when framebuffer objects are supported.
    All drivers support FBO's now, so in practice this shouldn't be
    a problem.

:040000 040000 ec74d4a0f7309302422fab97e8dc6154d34c1f05 5366f354c6f50765f77dd38e34640bde66de8ccb M      kwin
Comment 40 S. Christian Collins 2013-08-23 05:25:20 UTC
I can also confirm that manually removing that commit from the 4.11 source fixes the bug.
Comment 41 Thomas Lübking 2013-08-23 06:32:11 UTC
(In reply to comment #40)
> I can also confirm that manually removing that commit from the 4.11 source
> fixes the bug.
I was about to ask that ;-)

Many thanks for your efforts!

Don't forget to reset your local changes and ultimately the bisect.

No a random (wild) guess: try injecting "glFinish();" directly after 
either:
  glClearColor(0, 0, 0, 0);
or:
  glClear(GL_COLOR_BUFFER_BIT);

(not both at once)

If either works, also try replacing it by "glFlush();" - if nothing works, try it at the end of the function

-------------
    }

    if (fbo_bound)
        glBindFramebuffer(GL_FRAMEBUFFER, 0);
    glFinish();
}
----------------------
Comment 42 S. Christian Collins 2013-08-23 15:07:06 UTC
(In reply to comment #41)
> No a random (wild) guess: try injecting "glFinish();" directly after...

None of those options worked, unfortunately.
Comment 43 S. Christian Collins 2013-08-23 15:09:21 UTC
Well hold on... something's amuck. I just did what I thought was a reverting of the patch again, and now it's not working. Something is either not getting compiled or updated properly... let me investigate.
Comment 44 S. Christian Collins 2013-08-23 15:16:21 UTC
Nevermind that last comment. When I copied the reverted paintdirector.* files back into the /build/kwin directory, the compiler didn't recognize them as having been updated, and skipped compiling / reinstalling kwin. This didn't affect the glFinish(); etc. tests you wanted me to run.
Comment 45 Thomas Lübking 2013-09-01 18:02:36 UTC
*** Bug 324338 has been marked as a duplicate of this bug. ***
Comment 46 Thomas Lübking 2013-09-01 21:30:27 UTC
Created attachment 82097 [details]
Preserve pot. previous FBO and yell a warning if we had it overridden

(In reply to comment #44)
> didn't affect the glFinish(); etc. tests you wanted me to run.

Ok, coming back to this: either the issue is introduced by clearing the framebuffer or by the clamp_to_edge call.

We should better rule out that this is due to the latter which you can just comment out

// m_textures[i]->setWrapMode(GL_CLAMP_TO_EDGE);

If that's not the case, i wonder whether we might override a currently bound framebuffer - see attached patch. (Does it yell a warning and/or fix the issue?)
Comment 47 S. Christian Collins 2013-09-02 04:59:43 UTC
(In reply to comment #46)
> We should better rule out that this is due to the latter which you can just
> comment out
> 
> // m_textures[i]->setWrapMode(GL_CLAMP_TO_EDGE);

This did not fix the issue.

> If that's not the case, i wonder whether we might override a currently bound
> framebuffer - see attached patch. (Does it yell a warning and/or fix the
> issue?)

This didn't fix the issue either, and your "OUCH!" warning doesn't show up in the debug output.
Comment 48 Fredrik Höglund 2013-09-02 16:47:54 UTC
Try clearing the texture with glTexImage2D().
Comment 49 Johan Reitan 2013-09-03 09:11:09 UTC
Hi,
I want to report that I have this problem as well (although I've only experienced the missing corner bug). 

Running up-to-date Arch Linux (kernel 3.10.10)
Catalyst 13.8 beta 2
KDE 4.11
Comment 50 S. Christian Collins 2013-09-04 05:37:08 UTC
(In reply to comment #48)
> Try clearing the texture with glTexImage2D().

Sorry, I don't really know C++ well enough to know how to do this. I tried replacing the line that begins:
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, ... (etc)

with this:
glTexImage2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, ... (etc)

But that line caused a compile error (too few arguments to function), so I'm going to wait for more specific instructions before mangling the code any further. Also, do you want me to make the change on top of your patched version or on top of the original code?
Comment 51 Thomas Lübking 2013-09-04 11:00:03 UTC
Created attachment 82147 [details]
clear the texture the legacy way

=)

Fredrik probably meant to say:
"Hey Thomas, get your ass up and write the kindly testing user a legacy fallback since our assumption that fbo is supported everywhere might not hold for stupid fglrx"  ;-)

The patch is for vanilla 4.11 - forget about the filename, re-used other file.

It forcefully uses a legacy way to clear the texture and in addition yells a warning if generating the framebuffer actually failed. (It will actually be many warnings in case, you want to try from konsole and when figured whether s_fbo exists remove the debug out:
        if (!s_fbo)
            qDebug() << "MEGAFAIL: no framebuffer object support!";
before continue to use the patch.
Comment 52 S. Christian Collins 2013-09-04 13:46:52 UTC
(In reply to comment #51)
> Fredrik probably meant to say: ...
Whoops... I didn't realize that was Fredrik and not you.

Anyway, this patch works! The window side borders are no longer missing, and the "MEGAFAIL" error never shows either.
Comment 53 S. Christian Collins 2013-09-04 13:59:05 UTC
I also added additional qDebug() output to verify the method that was being used to clear the textures, and I can confirm that the new code (after "else") is indeed being used on my system.
Comment 54 Thomas Lübking 2013-09-04 17:27:25 UTC
Created attachment 82163 [details]
slightly modified variant

(In reply to comment #52)
> Whoops... I didn't realize that was Fredrik and not you.
nevermind.
 
> Anyway, this patch works! [...]

Can you give the replacement a quick check as well?

(In reply to comment #53)
> I can confirm that the new code (after "else") is indeed being used on my system.
Yes, "if (false)" is a pretty safe way ;-)
Comment 55 Fredrik Höglund 2013-09-04 21:49:48 UTC
Clearing the texture with glTexSubImage2D() might actually be faster than using glClear(),
because the glTexSubImage2D() call in updatePixmaps() will (should) stall on the GPU until the clear command has been executed.
Comment 56 S. Christian Collins 2013-09-04 21:56:33 UTC
Your latest patch throws the following compile errors:
paintredirector.cpp: In constructor ‘KWin::OpenGLPaintRedirector::OpenGLPaintRedirector(KWin::Client*, QWidget*)’:
paintredirector.cpp:326:10: error: ‘GLPlatform’ has not been declared
paintredirector.cpp:326:46: error: ‘Driver_Catalyst’ was not declared in this scope
Comment 57 Thomas Lübking 2013-09-05 06:39:36 UTC
(In reply to comment #56)
> Your latest patch throws the following compile errors:
> paintredirector.cpp: In constructor
> ‘KWin::OpenGLPaintRedirector::OpenGLPaintRedirector(KWin::Client*,
> QWidget*)’:
> paintredirector.cpp:326:10: error: ‘GLPlatform’ has not been declared
> paintredirector.cpp:326:46: error: ‘Driver_Catalyst’ was not declared in
> this scope

forgot to include a header, sorry.
i'll upload a compiling (and more optimized, given it might be preferred anyway) patch later this day.
Comment 58 Thomas Lübking 2013-09-05 19:18:21 UTC
Created attachment 82181 [details]
alternative approach, NOT USABLE AS FINAL PATCH

Please see updated patch here:
https://git.reviewboard.kde.org/r/112526/

Also, I attached a completely different test (but related) which you'd have to try WITHOUT applying the patch we know to resolve the issue (I'd just like the check whether this is related)

Many thanks for all your hard testing efforts.
Comment 59 S. Christian Collins 2013-09-05 20:08:25 UTC
(In reply to comment #58)
> Also, I attached a completely different test (but related) which you'd have
> to try WITHOUT applying the patch we know to resolve the issue (I'd just
> like the check whether this is related)

I'm not sure what to be testing for here. I don't see any difference with the left/right window border (still broken), if that's what you're looking for.
Comment 60 S. Christian Collins 2013-09-05 20:10:03 UTC
(In reply to comment #58)
> Many thanks for all your hard testing efforts.

My pleasure. I'm just glad I can contribute something, not being a programmer myself. I love the KDE project. Thank you for all the hard work you put into it!
Comment 61 Thomas Lübking 2013-09-05 20:42:10 UTC
(In reply to comment #59)

> I'm not sure what to be testing for here.
Whether it would fix anything.

> I don't see any difference with the left/right window border (still broken)
Ok, nevermind - was just a wild guess.

Thanks for ruling that out.
Comment 62 S. Christian Collins 2013-09-05 21:07:37 UTC
(In reply to comment #58)
> Please see updated patch here:
> https://git.reviewboard.kde.org/r/112526/

I can confirm that the updated patch works.
Comment 63 S. Christian Collins 2013-09-09 19:51:59 UTC
Created attachment 82245 [details]
kwin segfault opening Skype

I got this kwin segfault today when opening Skype (see attachment). It looks like it might be related to the latest changes (I'm using kwin compiled with your patch here: https://git.reviewboard.kde.org/r/112526/). I don't have the debug symbols installed, but I didn't know if I should try installing them alongside the custom-compiled kwin, so I didn't. Hopefully the output will give you enough information as-is.
Comment 64 Thomas Lübking 2013-09-09 20:03:10 UTC
(In reply to comment #63)

> like it might be related to the latest changes (I'm using kwin compiled with
> your patch here: https://git.reviewboard.kde.org/r/112526/)
Which version of it?
(It got major updates and the first version was .... errrr ... product of too much stress, coffee and no sleep - don't ask ;-)
Comment 65 S. Christian Collins 2013-09-10 04:49:29 UTC
Aah... it was an earlier version. I just now compiled with the latest version. I'll let you know if I run into any issues.
Comment 66 Jan Zoń 2013-09-10 09:52:05 UTC
Will this patch include in any KDE 4.11.x ??
Comment 67 Thomas Lübking 2013-09-10 10:36:16 UTC
(In reply to comment #66)
> Will this patch include in any KDE 4.11.x ??

It currently points 4.11.2 but i'll wait and see whether Christian just found "Thomas was too tired to write sane C code" or there's another issue with fglrx & glTexSubImage2D() at this point.

Fr 27. Sep 01:59:00 CEST 2013    :  KDE SC 4.11.2 tagging
Comment 68 Thomas Lübking 2013-09-10 18:40:01 UTC
*** Bug 324755 has been marked as a duplicate of this bug. ***
Comment 69 S. Christian Collins 2013-09-10 18:51:12 UTC
(In reply to comment #67)
> It currently points 4.11.2 but i'll wait and see whether Christian just
> found "Thomas was too tired to write sane C code" or there's another issue
> with fglrx & glTexSubImage2D() at this point.

I've been using my laptop for a few hours today without any crashes. I'll have it running all day for the next two days as well while I teach lessons. I'll let you know if I run into any more problems, but I'm guessing the segfaults were a result of "Thomas was too tired to write sane C code" ;)
Comment 70 S. Christian Collins 2013-09-13 00:04:20 UTC
Just to confirm, no more crashes after two full days of use, so the latest patch indeed seems to be stable.
Comment 71 phillmorley 2013-09-22 11:01:16 UTC
the effects dont work without using xrender. I use a silding panel and it is flat with no transparency effects and just appears and doesnt glide out. I am using the lastest beta catalyst

Also i spat my drink out when hearing the KDE devs probably dont use Catalyst ?! Not sure whether to laugh or cry here. The 3D performance dumps on the opensource (yes that is changing at a resonable pace) and the big pull for users is being able to play games and rich media using their AMD cards, the majority of people will be wanting the very best driver possible which is closed source and theres nothing wrong with that if it works good which it does!

thanks
Comment 72 Thomas Lübking 2013-09-22 12:08:49 UTC
(In reply to comment #71)
> the effects dont work without using xrender.
Likely bug #323527

> Also i spat my drink out when hearing the KDE devs probably dont use
> Catalyst ?!

Remember that in order to use fglrx, one needs to be willing to purchase the resp. HW in the first place.

Also not "KDE Devs" but "KWin Devs".
This means 3-4 ppl. with also a pretty good oversight on driver issues.

Now get another cup of coffee, boot your brain and think about it but personally i'm not avoiding fglrx for FLOSS concerns (eg. using the nvidia blob on 3 machines)
Comment 73 phillmorley 2013-09-22 21:11:09 UTC
good to hear it

might not matter too much for gaming in a day or so if valve release their Linux Steam box will use whatever that requires and normal linux desktop for work and internet.

thanks
Comment 74 Thomas Lübking 2013-09-23 23:12:15 UTC
Git commit da78b49a3698a3a11ea1c68e3b5af3cecd5c00d5 by Thomas Lübking.
Committed on 05/09/2013 at 19:10.
Pushed by luebking into branch 'KDE/4.11'.

introduce GLTexture::clear and use it from paintredirector

also work around broken fbo texture clearing on fglrx

so far supports FBO/glClear and resorts to glTexSubImage2D

if the fbo cannot be created or is (in case of fglrx)
known to break, resort to glTexImage2D loading of an
argb array of zeros
FIXED-IN: 4.11.2
REVIEW: 112526

M  +49   -23   kwin/libkwineffects/kwingltexture.cpp
M  +5    -0    kwin/libkwineffects/kwingltexture.h
M  +3    -1    kwin/libkwineffects/kwingltexture_p.h
M  +2    -32   kwin/paintredirector.cpp
M  +0    -3    kwin/paintredirector.h

http://commits.kde.org/kde-workspace/da78b49a3698a3a11ea1c68e3b5af3cecd5c00d5
Comment 75 Michał D. (Emdek) 2013-10-03 06:25:31 UTC
Seems to work fine now (KDE 4.11.2 and Catalyst 3.10-beta2), thanks. :-)