Bug 261069 - Kwin freezes and shows artefacts consistently after some time (KDE 4.6 RC1)
Summary: Kwin freezes and shows artefacts consistently after some time (KDE 4.6 RC1)
Status: RESOLVED DUPLICATE of bug 261323
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: git master
Platform: OpenSUSE Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-23 13:43 UTC by Jorge Adriano
Modified: 2011-01-18 22:30 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jorge Adriano 2010-12-23 13:43:56 UTC
Version:           SVN (using Devel) 
OS:                Linux

After using KDE for a while KWin consistently freezes and sometimes shows artefacts. 

KDE Version: 
  KDE 4.6 RC1. 

Distribution:
  OpenSUSE 11.3 - KDE Factory RPMs

Graphics Card and Drivers:
  Model:  GeForce 8600M GT
  2D driver:  nvidia
  3D driver:  NVIDIA 260.19.21

Note:
  Also affected KDE 4.6 Beta 2, with both NVIDIA 260.19 and the previous drivers I was using, NVIDIA 25x.xx.

Reproducible: Always

Steps to Reproduce:
Log in, use KDE for a little while

Actual Results:  
KWin freeze
Artefacts on screen


OS: Linux (i686) release 2.6.34.7-0.5-desktop
Compiler: gcc
Comment 1 Thomas Lübking 2010-12-23 15:03:58 UTC
how deep is the freeze? can you still suspend compositing (shift+alt+f12)?
is it maybe related to a specific effect (like "blur")?
Comment 2 Jorge Adriano 2010-12-23 15:32:08 UTC
(In reply to comment #1)
> how deep is the freeze? 

Begins with small freezes, of couple of seconds, then deeper freezes of many seconds.

> can you still suspend compositing (shift+alt+f12)?

During the freeze it is unresponsive but afterwords yes. When a deep freeze happens the composite is automatically suspended.

> is it maybe related to a specific effect (like "blur")?

I'd have to try it out. I downgrade meanwhile because I needed to work. I'll upgrade later to test that out. Please let me know if there's anything else you'd like me to check at that time, as I'll probably downgrade again.
Comment 3 Thomas Lübking 2010-12-23 17:38:38 UTC
this is probably nvidias PixmapCache re-allocating memory
Check whether it remains with "nvidia-settings -a InitialPixmapPlacement=0" (actually anything from [0,4] but "2" is fine, be aware that this might have performance or visual impacts, eg. "0" blinds titlebars and if you use the xrender backend, "0" is actually horribly slow)
Comment 4 Martin Flöser 2010-12-30 18:07:43 UTC
please try settings from comment#3
Comment 5 Jorge Adriano 2010-12-30 20:25:33 UTC
(In reply to comment #3)
> this is probably nvidias PixmapCache re-allocating memory
> Check whether it remains with "nvidia-settings -a InitialPixmapPlacement=0"
> (actually anything from [0,4] but "2" is fine, be aware that this might have
> performance or visual impacts, eg. "0" blinds titlebars and if you use the
> xrender backend, "0" is actually horribly slow)

Doesn't seem to freeze with value 0
Does freeze with value 2

Disabling/Enabling Blur doesn't seem to make a difference.
Comment 6 Jorge Adriano 2010-12-30 20:28:25 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > this is probably nvidias PixmapCache re-allocating memory
> > Check whether it remains with "nvidia-settings -a InitialPixmapPlacement=0"
> > (actually anything from [0,4] but "2" is fine, be aware that this might have
> > performance or visual impacts, eg. "0" blinds titlebars and if you use the
> > xrender backend, "0" is actually horribly slow)
> 
> Doesn't seem to freeze with value 0
> Does freeze with value 2
> 
> Disabling/Enabling Blur doesn't seem to make a difference.

Also yes with value 0 effects to have poor performance and some visual problems, even thought I am using OpenGL.
Comment 7 Martin Flöser 2010-12-30 20:53:40 UTC
probably not much we can do about it in that case. Setting to "driver bug"
Comment 8 Thomas Lübking 2010-12-30 20:55:34 UTC
you can flush the cache every now and then by calling "nvidia-settings -a
PixmapCache=0; nvidia-settings -a PixmapCache=1", what should prevent the
"occasional" hangs (but causes "explicit" ones) - also check "nvidia-settings
-q PixmapCacheRoundSizeKB" - the default is 1024. The bigger the value is, the
less such hangs should occur, but the longer they'll likely take.

Also try to use the "only titlebar" decoration mode as offered by at least
oxygen & bespin (for oxygen that means to set "no border" and NOT use the deco
attached shadows)

Also I always wanted to test whether this might be related to KDEs shared
memory usage for icons ('Option "AllowSHMPixmaps" "true"' in the device section
of /etc/X11/xorg.conf - it's by default off and nvidia says is prevents
internal optimizations...)
Comment 9 Jorge Adriano 2011-01-07 11:29:28 UTC
(In reply to comment #8)
> you can flush the cache every now and then by calling "nvidia-settings -a
> PixmapCache=0; nvidia-settings -a PixmapCache=1", what should prevent the
> "occasional" hangs (but causes "explicit" ones) - also check "nvidia-settings
> -q PixmapCacheRoundSizeKB" - the default is 1024. The bigger the value is, the
> less such hangs should occur, but the longer they'll likely take.

The hangs are not occasional. They are constant. It's more like the unfreezes are occasional.

> Also try to use the "only titlebar" decoration mode as offered by at least
> oxygen & bespin (for oxygen that means to set "no border" and NOT use the deco
> attached shadows)

If these are just workarounds to minimise the problem so I can use the desktop, it doesn't really matter much for me. I'll be using LXDE for now as KDE 4.6 is not very usable at the moment (mainly nvidia drivers related crashes). However if I misunderstood and you think trying these might help diagnose/fix the problem let me know and I'll give it a shot. I simply can't spend much time playing with my system these days, so I've got to minimize experiments to the essential.

 

> Also I always wanted to test whether this might be related to KDEs shared
> memory usage for icons ('Option "AllowSHMPixmaps" "true"' in the device section
> of /etc/X11/xorg.conf - it's by default off and nvidia says is prevents
> internal optimizations...)

I tried this, I hope. OpenSUSE 11.3 uses auto-configuration so there's no such file. I edited /etc/X11/xorg.conf.d/50-device.conf to read:

Section "Device"
  Identifier "Default Device"

  #Driver "radeon"

  ## Required magic for radeon/radeonhd drivers; output name
  ## (here: "DVI-0") can be figured out via 'xrandr -q'
  #Option "monitor-DVI-0" "Default Monitor"

  Option "AllowSHMPixmaps" "true"
EndSection


But I am not sure if this works. I noticed no difference. If anything the freeze was harder.
Comment 10 Jorge Adriano 2011-01-11 14:27:16 UTC
Still present after the new update to 260.19.29 (OpenSUSE RPMs)
Comment 11 Thomas Lübking 2011-01-11 15:28:02 UTC
Sorry, wanted to reply earlier.

a) No, allowing SHM pixmaps has no effect (tested myself)
b) maybe "occasional" was an improper term - let's say "random". Did you however try to flush the cache?
c) not using decoration borders (as well as the oxygen-deco internal shadows) will considerably shrink the size of the temp. ARGB pixmap allocated to render the decoration offscreen, what /might/ prevent the buffer stressing
Comment 12 Jorge Adriano 2011-01-17 02:18:38 UTC
Sorry... I just noticed what is causing the freeze. Should have realised this before. 

The problem is actually changing windows (Alt+Tab) with the Flip Cover effect. Other effects work fine. 

J.A.

(In reply to comment #11)
> Sorry, wanted to reply earlier.
> 
> a) No, allowing SHM pixmaps has no effect (tested myself)
> b) maybe "occasional" was an improper term - let's say "random". Did you
> however try to flush the cache?
> c) not using decoration borders (as well as the oxygen-deco internal shadows)
> will considerably shrink the size of the temp. ARGB pixmap allocated to render
> the decoration offscreen, what /might/ prevent the buffer stressing
Comment 13 Thomas Lübking 2011-01-17 16:14:42 UTC
(In reply to comment #12)
> The problem is actually changing windows (Alt+Tab) with the Flip Cover effect.
> Other effects work fine. 

errr... sorry, but:
"Flip swicth" (Vista-a-like) OR "Cover Switch" (Mac-a-like) ;-)

- Do you use "accurate" texture scaling?
- Does setting "smooth" fix it?
Comment 14 Jorge Adriano 2011-01-17 16:26:57 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > The problem is actually changing windows (Alt+Tab) with the Flip Cover effect.
> > Other effects work fine. 
> 
> errr... sorry, but:
> "Flip swicth" (Vista-a-like) OR "Cover Switch" (Mac-a-like) ;-)

Opss Flip switch!

> - Do you use "accurate" texture scaling?
> - Does setting "smooth" fix it?

I had smooth on (the one in the middle, set by default)
Comment 15 Thomas Lübking 2011-01-17 17:27:44 UTC
Can you try using the coverswitch effect instead and check whether the same issue occurs?
Comment 16 Jorge Adriano 2011-01-17 17:30:11 UTC
(In reply to comment #15)
> Can you try using the coverswitch effect instead and check whether the same
> issue occurs?

I tried them all, including cover switch. Only flip switch causes this.
Comment 17 Martin Flöser 2011-01-18 22:30:51 UTC

*** This bug has been marked as a duplicate of bug 261323 ***