Bug 6811

Created attachment 5543 [details]
Snapshot with smart MH

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.

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).

Should be fixed now

benh:

is this fixed in the Radeon driver or in the X server?

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.

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.

Same here. My experience exactly matches morgoth's.

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.

Created attachment 5588 [details]
Testcase for the problem

FWIW, the test case seems to work fine here with the patches from bug 6929.

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?

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

(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.

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.

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 ... ?

Created attachment 5682 [details]
Xorg configuration

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.

(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.

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.

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.

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.

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!

Michel:

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

Sorry about the noise :/

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?

> 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.

*** Bug 7338 has been marked as a duplicate of this bug. ***

Still broken in 1.2.99.0

Confirmed that the "Different version" patch attached to this bug report fixes 
it

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

(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.

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.

*** Bug 10059 has been marked as a duplicate of this bug. ***