Bug 6773 - EXA does slow region move
Summary: EXA does slow region move
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Eric Anholt
QA Contact: Xorg Project Team
Depends on:
Reported: 2006-04-28 15:03 UTC by Pierre Ossman
Modified: 2009-12-07 13:47 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:

exaMoveIn/exaMoveOut log on mach64 (60.97 KB, text/plain)
2006-04-29 10:29 UTC, George -
no flags Details
X.org log for above mentioned problem (81.18 KB, text/plain)
2008-04-05 16:38 UTC, Benjamin Lamowski
no flags Details
striped down xorg.conf (1.86 KB, application/octet-stream)
2008-04-05 16:38 UTC, Benjamin Lamowski
no flags Details
paludis outputs & uname -a (4.13 KB, application/octet-stream)
2008-04-05 16:41 UTC, Benjamin Lamowski
no flags Details
lspci -vv -nn (1.23 KB, application/octet-stream)
2008-04-05 16:41 UTC, Benjamin Lamowski
no flags Details

Description Pierre Ossman 2006-04-28 15:03:35 UTC
Somewhere between 7.1 RC1 and current CVS, EXA got noticable slower. It seems to
affect dragging windows and scrolling, so some operation involved in moving
large regions seems to be the culprit. The machine also uses a lot of CPU when

(spawned from bug 4668)
Comment 1 Erik Andren 2006-04-28 19:29:18 UTC
Care to do any profiling to pinpoint the issue a bit more?
Comment 2 Pierre Ossman 2006-04-28 19:32:49 UTC
Sure. Any special test procedure you want or should I just whip up oprofile and
fiddle a bit?
Comment 3 Eric Anholt 2006-04-29 07:22:21 UTC
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.
Comment 4 George - 2006-04-29 10:27:37 UTC
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 ...
Comment 5 George - 2006-04-29 10:29:05 UTC
Created attachment 5518 [details]
exaMoveIn/exaMoveOut log on mach64
Comment 6 George - 2006-04-29 23:15:15 UTC
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.
Comment 7 George - 2006-04-29 23:48:12 UTC
(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.
Comment 8 Pierre Ossman 2006-04-30 00:30:53 UTC
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 and can be done on any site.
Comment 9 George - 2006-04-30 01:47:15 UTC
(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 ?

Comment 10 Pierre Ossman 2006-04-30 03:55:03 UTC
Nope. Same sluggish behaviour.
Comment 11 Pierre Ossman 2006-04-30 08:41:28 UTC
I did some profiling when moving a window around and got:

    38009 64.7866 Xorg
          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
Comment 12 Eric Anholt 2006-05-01 15:51:11 UTC
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.
Comment 13 Pierre Ossman 2006-05-01 23:46:20 UTC
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.
Comment 14 Alex Deucher 2006-05-02 12:50:01 UTC
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.
Comment 15 Pierre Ossman 2006-05-04 18:55:04 UTC
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                    

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                    
Comment 16 Michel Dänzer 2006-05-16 01:43:36 UTC
Can you try the patches from bug 6929?
Comment 17 Pierre Ossman 2006-05-16 22:39:21 UTC
Fedora have updated to RC3 (I assume, version Can I use the patches
with that version?
Comment 18 Michel Dänzer 2006-05-17 00:15:01 UTC
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.
Comment 19 Pierre Ossman 2006-05-17 01:29:23 UTC
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.

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)
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
Comment 20 Pierre Ossman 2006-08-30 03:38:32 UTC
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.
Comment 21 Michel Dänzer 2006-08-30 05:44:54 UTC
(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?
Comment 22 Pierre Ossman 2006-08-30 05:59:31 UTC
The last test I did was at comment 17, so version
Comment 23 Michel Dänzer 2006-08-30 06:23:31 UTC
(In reply to comment #22)
> The last test I did was at comment 17, so version

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?
Comment 24 Pierre Ossman 2006-08-30 06:56:41 UTC
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.
Comment 25 Michel Dänzer 2006-08-30 07:38:25 UTC
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.
Comment 26 Pierre Ossman 2006-08-30 07:48:18 UTC
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?
Comment 28 Michel Dänzer 2006-08-30 08:22:41 UTC
Indeed, if it's disabled, it doesn't make a difference.
Comment 29 Daniel Stone 2007-02-27 01:31:48 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 30 Johannes Engel 2007-11-16 06:20:08 UTC
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.
Comment 31 Tobias Jakobi 2007-11-25 12:04:57 UTC
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.
Comment 32 Benjamin Lamowski 2008-04-05 16:36:37 UTC
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

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
Comment 33 Benjamin Lamowski 2008-04-05 16:38:23 UTC
Created attachment 15711 [details]
X.org log for above mentioned problem
Comment 34 Benjamin Lamowski 2008-04-05 16:38:58 UTC
Created attachment 15712 [details]
striped down xorg.conf
Comment 35 Benjamin Lamowski 2008-04-05 16:41:10 UTC
Created attachment 15713 [details]
paludis outputs & uname -a
Comment 36 Benjamin Lamowski 2008-04-05 16:41:28 UTC
Created attachment 15714 [details]
lspci -vv -nn
Comment 37 Michel Dänzer 2008-04-07 02:53:21 UTC
(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.
Comment 38 Benjamin Lamowski 2008-04-08 06:45:24 UTC
Sorry, I didn't test it with such small values for Virtual.
With "Virtual 2048 768" the problem does not occur.
Tank you.

Comment 39 Jerome Glisse 2009-12-07 13:47:33 UTC
Fixed according to:

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.