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