Bug 6811 - MigrationHeuristic smart cause heavy window decoration corruption under KDE
Summary: MigrationHeuristic smart cause heavy window decoration corruption under KDE
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: git
Hardware: Other Linux (All)
: high normal
Assignee: Keith Packard
QA Contact:
URL:
Whiteboard:
Keywords:
: 7338 10059 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-05-02 06:07 UTC by Marcin Kurek
Modified: 2007-02-22 03:05 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Snapshot with smart MH (924.00 KB, image/png)
2006-05-02 06:12 UTC, Marcin Kurek
no flags Details
Testcase for the problem (2.40 KB, text/plain)
2006-05-10 07:33 UTC, Fredrik Höglund
no flags Details
Xorg configuration (3.59 KB, text/plain)
2006-05-20 01:38 UTC, Marcin Kurek
no flags Details
Fix, or workaround? (752 bytes, patch)
2006-06-05 08:52 UTC, Michel Dänzer
no flags Details | Splinter Review
Different version (894 bytes, patch)
2006-06-05 09:10 UTC, Michel Dänzer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Kurek 2006-05-02 06:07:18 UTC
Enabling "smart" MigrationHeuristic cause here a window decoration corruption
under KDE (3.5.2) Setting it to greedy fix it and KDE looks fine.

It seems this problem is only KDE (Or Qt) related because window decorations
look's fine under Gnome for example.

Bug still can be reproduced with today snap of xorg server && ati drivers (1.05.06)
Comment 1 Marcin Kurek 2006-05-02 06:12:13 UTC
Created attachment 5543 [details]
Snapshot with smart MH
Comment 2 Marcin Kurek 2006-05-02 06:18:03 UTC
A small update to this report. It seems this corruption can be reproduced only
in few window decorations. On my system only 'Plastik' and 'Smooth Blend'
decorations are corrupted.
Comment 3 Francesco Biscani 2006-05-03 23:27:11 UTC
I get similar symptoms on my Radeon IGP 345M. Eric Anholt says that there are 
issues to be ironed out in the Radeon driver, so hopefully this will be fixed 
soon.

On a side note, have you tried running "xcompmgr -c" under kde with EXA+smart 
MH? For me it is awfully slow when displaying text (konsole and konqueror for 
example, but also when drawing the desktop).
Comment 4 Benjamin Herrenschmidt 2006-05-04 09:12:45 UTC
Should be fixed now
Comment 5 Francesco Biscani 2006-05-04 09:20:49 UTC
benh:

is this fixed in the Radeon driver or in the X server?
Comment 6 Marcin Kurek 2006-05-04 22:53:13 UTC
To be honest the EXA is realy slow for me in general. At last when I compare it
to XAA ... no ideas why. Enabling EXA makes Xorg much slower and less
responsible (Interactivity is realy low) When I run composite menager thing
become a bit faster (At last moving windows) but for example text rendering and
window resizing  become realy dead slow. Also when there is many windows opened
system starts to crawl (X eats almos all % CPU) also a big/complicated windows
(OpenOffice writer or Firefox) makes same problem.
 
Few weeks ago I give a try to oprofile to check the reason, but it lead me to
noting (I know only that most of the time X spends in libfb). It seems EXA is
much more cpu intensive then XAA for my relative slow machine (Pegasos II 1GHz)

Anyway for now I switched back to XAA and now after few weeks of EXA usage I
fell like flying ... realy.
Comment 7 Marcin Kurek 2006-05-05 06:17:13 UTC
Compiled xorg-server 03.05.06 and ati drivers 03.05.06 and this problem is
definitly still there. The KDE window decorations are still corrupted.
Comment 8 Francesco Biscani 2006-05-05 06:47:57 UTC
Same here. My experience exactly matches morgoth's.
Comment 9 Fredrik Höglund 2006-05-09 07:53:05 UTC
The bug appears to be that PolyFillRect is unable to handle 1xN sized tiles.
It doesn't matter if the destination drawable is a window or a pixmap.

The bug is reproduceable in Xephyr with fakexa, which suggests that this is an
EXA bug. It's not reproduceable in Xephyr without fakexa. Testcase coming up
shortly.
Comment 10 Fredrik Höglund 2006-05-10 07:33:13 UTC
Created attachment 5588 [details]
Testcase for the problem
Comment 11 Michel Dänzer 2006-05-16 01:44:29 UTC
FWIW, the test case seems to work fine here with the patches from bug 6929.
Comment 12 Francesco Biscani 2006-05-16 04:56:14 UTC
Michel:

the patches in the other bugreport do not make a difference here wrt graphics 
artifacts. Same corruptions in KDE using the Plastik windeco.

But they seem to make a difference in performance: everything seems smoother, 
but, above all, they improve _a lot_ the performance of a Qt4 application I'm 
working on. Previously this app was awfully slow in paint operations, now it 
is on par with the rest of the desktop. I'm about to drop XAA completely :)

The only negative note is that I have xorg crashes when using big transparent 
windows during workspace switching. It happened twice (while Xorg cvs never 
crashed on me during the past few months). Not sure if I can reproduce it 
reliably though...

Should I open new bugs for these issues? Wouldn't be handy to have a meta-bug 
for keeping track of all EXA quirks?
Comment 13 Francesco Biscani 2006-05-16 05:13:54 UTC
Michel:

got another crash. It's in exa, here's the log:

-------------------------
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x9f) [0x80bea14]
1: [0xffffe420]
2: /usr/lib/xorg/modules/libexa.so [0xb7ab7b45]
3: /usr/lib/xorg/modules/libexa.so(exaMoveOutPixmap+0x4b) [0xb7ab7c4a]
4: /usr/lib/xorg/modules/libexa.so [0xb7ab7cd6]
5: /usr/lib/xorg/modules/libexa.so(exaDoMigration+0x406) [0xb7ab8520]
6: /usr/lib/xorg/modules/libexa.so [0xb7ab561d]
7: /usr/bin/X [0x8148fb9]
8: /usr/bin/X(ProcPolyFillRectangle+0x19f) [0x8081081]
9: /usr/bin/X(Dispatch+0x18f) [0x8084823]
10: /usr/bin/X(main+0x483) [0x806d556]
11: /lib/libc.so.6(__libc_start_main+0xdb) [0xb7d87efb]
12: /usr/bin/X(FontFileCompleteXLFD+0x9d) [0x806c8a1]

Fatal server error:
Caught signal 11.  Server aborting
-------------------------

HTH
Comment 14 Michel Dänzer 2006-05-16 21:41:54 UTC
(In reply to comment #12)
> The only negative note is that I have xorg crashes when using big transparent 
> windows during workspace switching. It happened twice (while Xorg cvs never 
> crashed on me during the past few months). Not sure if I can reproduce it 
> reliably though...
> 
> Should I open new bugs for these issues?

Well, if this only happens with the patch from bug 6929, it's probably a
regression of that, and you should follow up there. It would be great if you
could build EXA with -g and get a backtrace with gdb.

I'm glad you're also seeing the performance improvements. :) I can't reproduce
the Plastik corruption, but I'm also using the patch from bug 6772, maybe that
makes a difference.
Comment 15 Marcin Kurek 2006-05-19 07:57:08 UTC
OK, finaly found some time to test this patches. Apply

https://bugs.freedesktop.org/attachment.cgi?id=5635
http://people.freedesktop.org/~anholt/damage-reportafter-2.diff
https://bugs.freedesktop.org/attachment.cgi?id=5512

And the corruptions are still there. The Plastik theme looks corrupted also the
yakuake console is affected.
Comment 16 Marcin Kurek 2006-05-20 01:37:17 UTC
Hmmm, it seems EXA with this patches is a bit unstable. It works MUCH faster
this is a fact, but I was hit by 2-3 unexpected Xorg lockups.

It's hard to say what cause that but it seems to be more frequent in Kde than in
Gnome. I was unable to find anything in log's propably because disk caches (I am
unable to use Syseq to sync FS after lockup because my keyboard doesn't handle
so many key's pressed at once)

BTW I wonder is there a way to map the SysReq keys to something else than
Ctrl+Alt+SysReq+Key ... ?
Comment 17 Marcin Kurek 2006-05-20 01:38:20 UTC
Created attachment 5682 [details]
Xorg configuration
Comment 18 Marcin Kurek 2006-05-27 07:39:22 UTC
OK, this seems to be KDE/QT related. On my system there is realy easy way to
reproduce it. Set MigrationH to "greedy" and run KDE (3.5.2 here) In most cases
I  get almost instantly lockup.

I can still move the mouse pointer, but the desktop seems to be freezed completlty.
Comment 19 Francesco Biscani 2006-05-28 00:54:52 UTC
(In reply to comment #18)
> OK, this seems to be KDE/QT related. On my system there is realy easy way to
> reproduce it. Set MigrationH to "greedy" and run KDE (3.5.2 here) In most 
cases
> I  get almost instantly lockup.
> 
> I can still move the mouse pointer, but the desktop seems to be freezed 
completlty.

I would like to add that I have serious performance issues in KDE when _not_ 
using anti-aliased text. Seems illogic, but without anti-aliased text many 
seconds are needed to redraw the desktop background when switching workspace.

IMHO Xorg hackers should always test this kind of stuff _at least_ on both GTK 
and Qt. Ignoring one of the toolkits is cutting out half of the people.
Comment 20 Michel Dänzer 2006-06-05 08:52:20 UTC
Created attachment 5824 [details] [review]
Fix, or workaround?

I tracked this down to the fbPadPixmap() call in exaValidateGC(); for some
reason, it doesn't seem to work correctly if the GC tile pixmap is offscreen.
This patch moves it out to system RAM, which fixes both the testcase and KDE
here. It's possible that this is just a workaround for a driver coherency bug
though, but then I'd be surprised that the corruption remains constant over the
whole width of the repeated tile... but I don't see why fbPadPixmap wouldn't
work on the offscreen pixmap either.
Comment 21 Michel Dänzer 2006-06-05 09:10:13 UTC
Created attachment 5825 [details] [review]
Different version

Actually, something like this may be needed; I'm working with a different
codebase due to bug 6929.
Comment 22 Marcin Kurek 2006-06-05 12:11:05 UTC
Applied https://bugs.freedesktop.org/attachment.cgi?id=5825 to xserver CVS snap
from 31.05.2006 and it seems this realy cure KDE corruption. Can we close this
bug then ? The corruptions are gone.

Switching back to EXA reminds me how ugly slow it can be :/ At last without
patches from https://bugs.freedesktop.org/show_bug.cgi?id=6929. The system works
almos fine but if I open firefox and XChat for example on he same workspace the
X starts to eat 90% of the cpu time and there is hard to make anything.

I hope lockups from #6929 will be fixed someday.
Comment 23 Francesco Biscani 2006-06-06 12:30:20 UTC
Hello,

the patch solves the problem for me too. I'm using EXA in KDE now, and I have 
not noticed any corruptions yet :)

On a side note, would it be possible to have an updated version of the patch 
in 6929? It does not apply cleanly against latest CVS. I would like to compile 
Xorg with debug enabled and try to get a backtrace of the crash I spoke about 
in the other bugreport.

Thanks!
Comment 24 Francesco Biscani 2006-06-06 13:13:15 UTC
Michel:

forget about my last request, I was working on the wrong CVS tree..

Sorry about the noise :/
Comment 25 Michel Dänzer 2006-06-21 06:42:34 UTC
From https://bugs.freedesktop.org/show_bug.cgi?id=6877#c13:

> Now, you remind me of your workaround for tiled pixmaps which is a dependency
> for correctness:

Interesting; if this is also needed with the mach64 driver, that makes it less
likely to be a driver bug. George, do you have any idea why the fbPadPixmap()
call wouldn't work in video RAM though?
Comment 26 George - 2006-06-21 08:10:01 UTC
> Interesting; if this is also needed with the mach64 driver, that makes it less
> likely to be a driver bug. George, do you have any idea why the fbPadPixmap()
> call wouldn't work in video RAM though?

Sorry, no clue. I really admire your ability to track down this kind of stuff :-)

Just to play it safe, mach64 and radeon exa have a common ancestor in the
kdrive/ati driver I think.
Comment 27 Michel Dänzer 2006-06-27 00:36:02 UTC
*** Bug 7338 has been marked as a duplicate of this bug. ***
Comment 28 Bernhard Rosenkraenzer 2006-11-05 04:11:12 UTC
Still broken in 1.2.99.0
Comment 29 Bernhard Rosenkraenzer 2006-11-05 07:12:14 UTC
Confirmed that the "Different version" patch attached to this bug report fixes 
it
Comment 30 Arkadiusz Miskiewicz 2006-12-04 05:12:01 UTC
I'm also having the same problem - broken window decoration under KDE but I also 
see serious cpu usage when in smart mode. greedy heuristic works fine (no broken 
window decoration and no high cpu usage). See:
http://lists.freedesktop.org/archives/xorg/2006-December/020175.html

I also tested ,,Different version'' patch with smart mode and kde window 
decoration problem is fixed BUT very high cpu usage is still there.

xorg 1.1.99.903, mesa 6.5.2 final, radeon mobile x600, video-ati 6.6.3
Comment 31 Michel Dänzer 2006-12-04 05:26:58 UTC
(In reply to comment #30)
> I'm also having the same problem - broken window decoration under KDE but I also 
> see serious cpu usage when in smart mode. greedy heuristic works fine (no broken 
> window decoration and no high cpu usage).

See the history of this bug, bug 6929 and friends...

At least the former is just because greedy doesn't bother to move the pixmap
offscreen in the first place. The same goes likely for your perceived
performance, as keeping things in system RAM avoids migration overhead (while
also preventing acceleration). The migration overhead with "smart" and "always"
should be better with the exa-damagetrack branch of xserver git.
Comment 32 Eric Anholt 2006-12-28 13:39:30 UTC
I think the original "Fix, or workaround" patch should be sufficient, so I'm
marking this bug closed since I expect that people's reports of success with the
second patch should be the same with the first, committed version.
Comment 33 Michel Dänzer 2007-02-22 03:05:42 UTC
*** Bug 10059 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.