| Summary: | EXA does slow region move | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Pierre Ossman <pierre-bugzilla> | ||||||||||||
| Component: | Server/Acceleration/EXA | Assignee: | Eric Anholt <eric> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | high | CC: | alexdeucher, ben-bugs, freedesktop, fufutos610, jcnengel, michel, murrayc, projects.gg.aaron | ||||||||||||
| Version: | git | ||||||||||||||
| Hardware: | x86 (IA32) | ||||||||||||||
| OS: | Linux (All) | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Pierre Ossman
2006-04-28 15:03:35 UTC
Care to do any profiling to pinpoint the issue a bit more? Sure. Any special test procedure you want or should I just whip up oprofile and fiddle a bit? The oprofile information would probably be useful. But this report is missing information on what exact day and time of CVS was tested, what desktop environment, what apps were being scrolled/moved over, whether there was a compmgr running, etc, so there's no way to try to reproduce the specific bad behavior reported. Sorry for jumping in.
I see similar symptoms with current CVS exa/smart on mach64 (solid/copy),
exa/greedy is fine.
This is the oprofile output for the following scenario:
xfwm4 (no compositor), xterm and firefox running
start oprofile
visit xorg-list, pgup, pgdown
stop oprofile
64130 60.7453 libc-2.3.5.so
35346 33.4805 no-vmlinux
1457 1.3801 firefox-bin
676 0.6403 oprofiled
569 0.5390 libfb.so
526 0.4982 Xorg
430 0.4073 libxpcom_core.so
327 0.3097 libexa.so
307 0.2908 libgobject-2.0.so.0.800.3
264 0.2501 libfontconfig.so.1.0.4
256 0.2425 libmozjs.so
228 0.2160 libglib-2.0.so.0.800.3
179 0.1696 libgdk-x11-2.0.so.0.800.6
165 0.1563 mach64_drv.so
152 0.1440 bash
I also attach the exa log for exaMoveInPixmap/exaMoveOutPixmap corresponding to
the oprofile session (my unconfirmed theory is that it is moving pixmaps in and
out and libc in oprofile means memcpy ...).
Does exa/smart require acceleration of specific composite operations (I mean for
typical desktop apps) ? Maybe 7.1 release notes should provide guidelines which
scheme to use depending on the driver ...
Created attachment 5518 [details]
exaMoveIn/exaMoveOut log on mach64
It seems that exa/smart requires composite operations of the following type to
be accelerated (for 16bit display) in order to work well:
src 0x8420ce8: fmt ARGB8888 (1x1 R),
mask 0x83f61a0: fmt A8 (7x9),
dst 0x8447038: fmt RGB565 (999x17),
If I pretend to accelerate *only* the above composite operation, then exa/smart
performs fine (fonts don't appear ok, of course), otherwise it moves pixmaps in
and out as in comment #4.
(In reply to comment #6) > It seems that exa/smart requires composite operations of the following type to > be accelerated (for 16bit display) in order to work well: > > src 0x8420ce8: fmt ARGB8888 (1x1 R), > mask 0x83f61a0: fmt A8 (7x9), > dst 0x8447038: fmt RGB565 (999x17), > Operation is PictOpOver. The build was from CVS 2006-04-27 08:50 CEST. No composition manager active. Applications were a standard gnome 2.14 desktop (i.e. nautilus occupying most of the screen) and a gnome-terminal being moved around. Scrolling was done with firefox 1.5.0.2 and can be done on any site. (In reply to comment #8) > The build was from CVS 2006-04-27 08:50 CEST. No composition manager active. > > Applications were a standard gnome 2.14 desktop (i.e. nautilus occupying most of > the screen) and a gnome-terminal being moved around. > is there a difference moving the gnome-terminal over desktop-icons vs. moving over background image only ? Nope. Same sluggish behaviour. I did some profiling when moving a window around and got:
38009 64.7866 Xorg
CPU_CLK_UNHALT...|
samples| %|
------------------
25109 66.0607 libfb.so
5876 15.4595 libc-2.4.90.so
2932 7.7140 vmlinux
1289 3.3913 Xorg
1100 2.8941 libexa.so
882 2.3205 radeon
603 1.5865 radeon_drv.so
44 0.1158 uhci_hcd
32 0.0842 libextmod.so
31 0.0816 ipw2200
29 0.0763 synaptics_drv.so
16 0.0421 yenta_socket
14 0.0368 libdri.so
10 0.0263 ehci_hcd
9 0.0237 libXfont.so.1.4.1
5 0.0132 ohci1394
5 0.0132 libramdac.so
5 0.0132 libdrm.so
4 0.0105 snd_intel8x0
3 0.0079 snd_intel8x0m
2 0.0053 hci_usb
2 0.0053 ieee80211
2 0.0053 libm-2.4.90.so
2 0.0053 libglx.so
2 0.0053 mouse_drv.so
1 0.0026 libdbe.so
Checking what it's up to with opreport -l gives:
23718 40.4282 libfb.so Xorg fbRasterizeEdges
5526 9.4193 libc-2.4.90.so Xorg memcpy
George: that Composite op is the usual one for antialiased text. I have never focused much attention on EXA/KAA performance without accelerated Render -- it's always seemed like the wrong place to focus my attention (rather than on getting drivers to implement it, which they all could). I would entertain ideas to improve the migration, still, but that should happen in a separate bug. Pierre: That's an interesting profile. You're seeing slow trapezoid rasterization (presumably -- I've never encountered a Triangles consumer). Since the current Trapezoids spec prevents hardware acceleration as far as I've been able to figure out so far, EXA has little control except through migration (when the temporary pixmap gets moved into framebuffer or system memory). I'll have to review the code and see what could be going wrong with migration, if your server is all that's changed. Nothing else changed, no. The performance hit first appeared when I switched from Red Hat's packaged 7.1 RC1 to CVS as part of testing patches proposed in other bugs here. The problem was present before I updated the radeon driver so the problem is contained to the server. I'm seeing the same thing with exa on savage, cvs as of 4/28/06 or 4/29/06 IIRC. I'm probably in the same boat as George though since I don't accelerate composite yet. I did a new test where I miminised a firefox window, revealing a thunderbird window. Now I got: samples % image name app name symbol name 28393 52.0409 libc-2.4.90.so Xorg memcpy 5236 9.5970 libfb.so Xorg fbRasterizeEdges 2682 4.9158 processor processor (no symbols) 2104 3.8564 oprofiled oprofiled (no symbols) 730 1.3380 libfb.so Xorg fbCompositeSrc_8888x8888mmx Scrolling in firefox (on this bug page) gave similar results to moving the gnome-terminal across a nautilus desktop: samples % image name app name symbol name 49166 55.6914 libfb.so Xorg fbRasterizeEdges 3990 4.5196 oprofiled oprofiled (no symbols) 2911 3.2974 libc-2.4.90.so Xorg memcpy 2323 2.6313 processor processor (no symbols) 2121 2.4025 libfb.so Xorg fbCompositeSrc_8888x8888mmx Can you try the patches from bug 6929? Fedora have updated to RC3 (I assume, version 1.0.99.903). Can I use the patches with that version? The miext/damage patch yes, the exa patch not directly. Manual merging shouldn't be too hard though, or you should be able to just drop the exa directory from CVS HEAD into an xserver 1.1 tree and built with that. Manual merging wasn't obvious, so I took Red Hat's RC3 and copied in /exa from HEAD. I then applied the two patches. But when running with EXA on, I get this during my GNOME startup: *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x9f) [0x80c485f] 1: [0xffffe420] 2: /lib/libc.so.6(memcpy+0x1c) [0xb7e1e56c] 3: /usr/lib/xorg/modules/drivers/radeon_drv.so(RADEONHostDataBlitCopyPass+0x62) [0xb7c717f2] 4: /usr/lib/xorg/modules/drivers/radeon_drv.so [0xb7ca091e] 5: /usr/lib/xorg/modules/libexa.so(exaMoveInPixmap+0x1b8) [0xb7b1df88] 6: /usr/lib/xorg/modules/libexa.so(exaDoMigration+0x48c) [0xb7b1e5fc] 7: /usr/lib/xorg/modules/libexa.so [0xb7b1cb61] 8: /usr/bin/Xorg [0x81565d1] 9: /usr/bin/Xorg(compPaintWindowBackground+0x6d) [0x8194d2d] 10: /usr/bin/Xorg(miClearToBackground+0x1b5) [0x8123f95] 11: /usr/bin/Xorg(ProcClearToBackground+0xb6) [0x8082a26] 12: /usr/bin/Xorg(Dispatch+0x19a) [0x8086dda] 13: /usr/bin/Xorg(main+0x485) [0x806e805] 14: /lib/libc.so.6(__libc_start_main+0xdc) [0xb7dc87e4] 15: /usr/bin/Xorg(FontFileCompleteXLFD+0xb9) [0x806db41] Fatal server error: Caught signal 11. Server aborting I am now running xorg-x11-server-Xorg-1.1.1-31.fc6 and the problem no longer remains. So feel free to close bug. (In reply to comment #20) > I am now running xorg-x11-server-Xorg-1.1.1-31.fc6 and the problem no longer > remains. Which version were you running previously? The last test I did was at comment 17, so version 1.0.99.903. (In reply to comment #22) > The last test I did was at comment 17, so version 1.0.99.903. Hmm, there only seem to be two small EXA changes between these versions, namely commits f8330f8d0fe1cdd4bca117537c7d1e918436ee3b and fe99f25e979ef3c0e7cd8ba68ae46a7c18cb9fd3. Have you tried the git server-1_1-branch to rule out a Fedora patch? Nope. I could try building the Fedora package without any patches, but not right now. Have you considered that the problem might be solved by some changes in the radeon driver? This is the somewhat scary list of patches in Fedora's build: Patch0: xorg-x11-server-0.99.3-init-origins-fix.patch # https://bugs.freedesktop.org/show_bug.cgi?id=5093 Patch1: xorg-server-0.99.3-fbmmx-fix-for-non-SSE-cpu.patch Patch3: xserver-1.0.0-parser-add-missing-headers-to-sdk.patch Patch4: xorg-x11-server-1.0.1-composite-fastpath-fdo4320.patch Patch5: xorg-x11-server-libxf86config-dont-write-empty-sections.patch Patch6: xorg-x11-server-1.1.1-builderstring.patch Patch7: xorg-x11-server-1.1.1-xkb-in-xnest.patch Patch8: xorg-x11-server-1.1.1-xvfb-composite-crash.patch # OpenGL compositing manager feature/optimization patches. Patch100: xorg-x11-server-1.1.0-no-move-damage.patch Patch101: xorg-x11-server-1.1.0-dont-backfill-bg-none.patch Patch103: xorg-x11-server-1.1.0-tfp-damage.patch Patch104: xorg-x11-server-1.1.0-mesa-copy-sub-buffer.patch Patch105: xorg-x11-server-1.1.1-enable-composite.patch Patch106: xorg-x11-server-1.1.1-no-composite-in-xnest.patch Patch107: xorg-x11-server-1.1.1-offscreen-pixmaps.patch Patch108: xorg-x11-server-1.1.1-mesa-6.5.1.patch Patch109: xorg-x11-server-1.1.1-aiglx-happy-vt-switch.patch # Red Hat specific tweaking, not intended for upstream # XXX move these to the end of the list Patch1000: xorg-redhat-die-ugly-pattern-die-die-die.patch Patch1001: xorg-x11-server-Red-Hat-extramodes.patch Patch1002: xorg-x11-server-1.1.0-redhat-xephyr-only-hack.patch Patch1003: xorg-x11-server-1.0.1-fpic-libxf86config.patch Patch1004: xorg-x11-server-1.1.1-selinux-awareness.patch # Backports of post-1.1 stuff. Patch2001: xorg-x11-server-1.1.0-pci-scan-fixes.patch Patch2004: xorg-x11-server-1.1.0-no-zlib.patch Patch2005: xorg-x11-server-1.1.1-Xdmx-render-fix-fdo7482.patch Patch2006: xorg-x11-server-1.1.1-revert-xkb-change.patch Patch2007: xorg-x11-server-1.1.1-aiglx-locking.patch # autoconfiguration feature patches Patch3001: xorg-x11-server-1.1.0-edid-mode-injection-1.patch Patch3002: xorg-x11-server-1.1.0-edid-mode-injection-2.patch Patch3003: xorg-x11-server-1.1.0-cvt-generator-in-core.patch Patch3004: xorg-x11-server-1.1.0-no-autoconfig-targetrefresh.patch Patch3005: xorg-x11-server-1.1.1-getconfig-pl-die-die-die.patch Patch3006: xorg-x11-server-1.1.1-dpms-on-by-default.patch Patch3007: xorg-x11-server-1.1.1-edid-root-window-properties.patch Patch3008: xorg-x11-server-1.1.1-sanedefaultmode.patch Patch3009: xorg-x11-server-1.1.1-module-list.patch Patch3010: xorg-x11-server-1.1.1-edid-quirks-list.patch Patch3011: xorg-x11-server-1.1.1-defaultdepth-24.patch Patch3012: xorg-x11-server-1.1.1-always-mouse-thyself.patch Patch3013: xorg-x11-server-1.1.1-fix-default-mouse-device-yet-again.patch Patch3014: xorg-x11-server-1.1.1-infer-virtual.patch Patch3015: xorg-x11-server-1.1.1-mode-sort-kung-fu.patch Patch3016: xorg-x11-server-1.1.1-pci-paranoia.patch The names can of course not convey all of what the patch does, but they give a hint at least. Do any of these touch the exa directory? They're not very likely to make the difference otherwise. If you're running xf86-video-ati 6.6.2, at least some of the difference could be due to AccelDFS. Nope. A grep of the patches reveals that noone touches that dir. This is the first I heard of AccelDFS, and from the patch I can find[1] it seems to be disabled for AGP cards. So should it really affect anything? Indeed, if it's disabled, it doesn't make a difference. Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. Using X.Org xserver 1.4 on my intel 945GM together with intel-driver 2.2.0 this problem is not that hard as it was before for me, but still scrolling (in firefox, kate, or whatever you like) causes about 60% of CPU load of a intel Core2Duo. The problem does not occur using XAA. Confirming this problem with xorg-server-1.4, xf86-video-intel-2.2.0 and an i915 chipset. Scrolling is slow, resizing windows (its even more extreme than scrolling) and letting something compile in a terminal windows (so another scrolling text example). Resizing also leads to sound dropouts, I never experienced this before even under very heavy system load. Minimizing and maximizing windows has extreme lag. Even when repeatedly minimizing/maximizing the same window. Takes an insane amount of time and eats a lot of CPU cycles. I'm having this kind of bug since I first really configured the driver on my notebook, about 3/4 year ago. Short description (see attachments): - Hardware: Radeon RC250 [Mobility FireGL 9000] 32MB - x11-drm 20071019, xf86-video-ati 6.8.0, xorg-server 1.4.0.90-r3 Steps to reproduce: - fire up basic X, only driver options: Option "AccelMethod" "EXA" - it doesn't matter if this is true: Option "AccelDFS" "true" -> xrandr --output VGA-0 --same-as LVDS: moving windows works fine -> xrandr --output VGA-0 --right-of LVDS --mode 1024x768 (resolutions do not matter): moving windows is unbearable slow - the above mentioned does not happen w/ XAA Created attachment 15711 [details]
X.org log for above mentioned problem
Created attachment 15712 [details]
striped down xorg.conf
Created attachment 15713 [details]
paludis outputs & uname -a
Created attachment 15714 [details]
lspci -vv -nn
(In reply to comment #32) > -> xrandr --output VGA-0 --right-of LVDS --mode 1024x768 (resolutions do not > matter): moving windows is unbearable slow Does it really not matter whether the virtual screen width as reported by xrandr is larger than 2048? If it does, this should be fixed in current xf86-video-ati Git. Sorry, I didn't test it with such small values for Virtual. With "Virtual 2048 768" the problem does not occur. Tank you. Fixed according to: http://bugs.freedesktop.org/show_bug.cgi?id=6773#c38 |
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.