Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 147841 - EXA slower with xorg-server-1.1.1-r1
Summary: EXA slower with xorg-server-1.1.1-r1
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on: 151666
Blocks: 144549
  Show dependency tree
 
Reported: 2006-09-16 11:35 UTC by Giacomo Perale
Modified: 2006-12-06 19:43 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Giacomo Perale 2006-09-16 11:35:55 UTC
Hello, I upgraded xorg-server to the new release 1.1.1-r1 this morning, and I noticed a clear performance drop with EXA enabled. This is visible not only when I move transparent windows around but also when I scroll web pages in firefox, documents in evince or text in gnome-terminal, when I switch virtual desktop and when I resize windows etc. etc.

I tried to compile xorg without the 0* patches to find if they're the culprit, but the build fails. 

My video card is a Radeon 7500 (R100), with the DRI driver. I also noticed that Xorg.0.log included this new warnings:

(WW) AIGLX: 3D driver claims to not support visual 0x23
(WW) AIGLX: 3D driver claims to not support visual 0x24
(WW) AIGLX: 3D driver claims to not support visual 0x25
(WW) AIGLX: 3D driver claims to not support visual 0x26
(WW) AIGLX: 3D driver claims to not support visual 0x27
(WW) AIGLX: 3D driver claims to not support visual 0x28
(WW) AIGLX: 3D driver claims to not support visual 0x29
(WW) AIGLX: 3D driver claims to not support visual 0x2a
(WW) AIGLX: 3D driver claims to not support visual 0x2b
(WW) AIGLX: 3D driver claims to not support visual 0x2c
(WW) AIGLX: 3D driver claims to not support visual 0x2d
(WW) AIGLX: 3D driver claims to not support visual 0x2e
(WW) AIGLX: 3D driver claims to not support visual 0x2f
(WW) AIGLX: 3D driver claims to not support visual 0x30
(WW) AIGLX: 3D driver claims to not support visual 0x31
(WW) AIGLX: 3D driver claims to not support visual 0x32

emerge --info output:

Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-ck1-r3 i686)
=================================================================
System uname: 2.6.17-ck1-r3 i686 AMD Athlon(tm) XP 1700+
Gentoo Base System version 1.12.5
Last Sync: Sat, 16 Sep 2006 15:30:06 +0000
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.3-r1, 2.0.28-r1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--alphabetical"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/ http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/"
LANG="it_IT"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -s"
LINGUAS="it en"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/dati/wd31gb/portage-tmp/"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext X a52 aac acpi alsa bash-completion berkdb bitmap-fonts bzip2 cairo cdr cli crypt cups curl dbus dlloader dri dts dvd dvdr eds elibc_glibc emboss encode exif fam fbcon ffmpeg firefox flac fortran gdbm gif glitz gnome gpm gstreamer gtk hal imagemagick input_devices_keyboard input_devices_mouse isdnlog java jce jpeg kdeenablefinal kernel_linux lcms libg++ linguas_en linguas_it mad mmx mmxext mng mono mp3 mpeg musepack mysql ncurses nls nntp nptl nptlonly nsplugin ogg opengl pam pcre pdf perl png ppds pppd python quicktime readline real reflection samba sdl session sndfile spell spl sse ssl startup-notification svg svga tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU video_cards_radeon vorbis win32codecs wmf x264 xcomposite xml xorg xv xvid zlib"
Unset:  CTARGET, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Donnie Berkholz (RETIRED) gentoo-dev 2006-09-16 14:18:39 UTC
It could be the change to mesa 6.5.1. If you're comfortable editing the ebuild, try removing xorg-x11-server-1.1.1-mesa-6.5.1.patch from PATCHES and changing MESA_PV="6.5.1" to "6.5" instead.
Comment 2 Giacomo Perale 2006-09-16 16:05:15 UTC
(In reply to comment #1)
> It could be the change to mesa 6.5.1. If you're comfortable editing the ebuild,
> try removing xorg-x11-server-1.1.1-mesa-6.5.1.patch from PATCHES and changing
> MESA_PV="6.5.1" to "6.5" instead.
> 

I've just compiled xorg-server with those changes: it is still slow, so the change to mesa 6.5.1 is not the cause of the problem. The AIGLX warnings disappeared.

Comment 3 Donnie Berkholz (RETIRED) gentoo-dev 2006-09-16 16:11:30 UTC
Now that you've made those changes, you could try removing all the 0[0-9]* patches from PATCHES again..
Comment 4 Giacomo Perale 2006-09-16 16:43:01 UTC
(In reply to comment #3)
> Now that you've made those changes, you could try removing all the 0[0-9]*
> patches from PATCHES again..
> 

Oh, sorry, I didn't read the message. However, I think I have found the problem: I recompiled xorg-server WITH mesa 6.5.1 and all the patches EXCEPT 02-dont-backfill-bg-none.patch and now everything is fast again. 

There is only a problem, when I set the transparency of a window with transset CPU usage grows and its movements are jerky for a while (~1s). This happened with 1.1.0 as well but not with 1.1.1-r1.
Comment 5 Donnie Berkholz (RETIRED) gentoo-dev 2006-09-16 16:59:32 UTC
The aiglx patches (all the 0[0-9]* ones) come from Kristian H
Comment 6 Donnie Berkholz (RETIRED) gentoo-dev 2006-09-16 16:59:32 UTC
The aiglx patches (all the 0[0-9]* ones) come from Kristian Høgsberg <krh@bitplanet.net>. You'll have to contact him personally with issues. Please keep us posted on it. Note that he's not a Gentoo user, so talking about portage won't get you far. =)
Comment 7 Giacomo Perale 2006-09-20 13:01:38 UTC
I just received an answer from Kristian H
Comment 8 Giacomo Perale 2006-09-20 13:01:38 UTC
I just received an answer from Kristian Høgsberg. He says at the patches assume XAA and under EXA there are at least "a couple of things" that don't work and that everything is untested. He says also that a better compatibility with EXA at the moment isn't a priority, and "for now it remains an XAA specific hack."

I did some tests, and I can confirm that compiz (the portage version) crashes the X server when I try to run it with EXA enabled and it works decently with XAA and xorg-server without the 02 patch.

My suggestions are:

1) add an einfo to the ebuilds (xorg-server and compiz) warning the users that they have to use XAA acceleration and disable EXA in xorg.conf
2) remove the 02 patch from the xorg-server ebuild, so that EXA/xcompmgr users have a properly working server (I don't know what is the performance impact of this change to compiz users, but since compiz is alpha software I think that we should favour the stable EXA)
Comment 9 Giacomo Perale 2006-09-29 14:38:00 UTC
Any news on this? Now Gentoo supplies a broken xorg to its users: upstream supports and advertises EXA as stable and working on the radeon cards, but a Gentoo local patch, known faulty, breaks it.
Comment 10 Donnie Berkholz (RETIRED) gentoo-dev 2006-09-29 15:28:03 UTC
Hey hanno, could you test without the 02 patch to xorg-server and make sure things still work fine w aiglx+compiz, or CC someone else who uses it?
Comment 11 Hanno Böck gentoo-dev 2006-09-30 11:07:15 UTC
Donnie: Removing the 02-patch causes some screen flickering on gpu-intensive effects with compiz.
Thus still everything works, performance lacks a bit more. I leave it up to you if you remove it, but if you could wait 1-2 days, I'll try to get kristian on irc and ask him if there's a better solution, maybe I'll hack something together to conditionally enable the code section on exa enabled.
Comment 12 Kristian Høgsberg 2006-10-03 21:38:01 UTC
02-dont-backfill-bg-none.patch should not cause any slowdowns.  It was added to prevent the X server from copying from framebuffer to host memory pixmaps when exposing bg=none window.  Without this patch, exposure of bg=none windows will cause an expensive readback from framebuffer.  Either way, the patch removes a copy operation, so it should never cause a slowdown.
Comment 13 Giacomo Perale 2006-10-04 09:30:06 UTC
I didn't wrote before that I've been using xcompmgr in the last months, because it is (was?) the only working compositing manager on my machine. 
I don't know if it's useful, but I tried to remove the 02 patch because I noticed that when I switched virtual desktops or windows the newly created windows became black for a moment before being actually painted, and the patch had a name which seemed to be "correlated" to that behaviour.
Comment 14 Donnie Berkholz (RETIRED) gentoo-dev 2006-10-10 19:21:44 UTC
I'm gonna have to hide this patch behind USE=aiglx before we go stable.
Comment 15 Hanno Böck gentoo-dev 2006-10-11 13:28:34 UTC
Reporter: Can you catch me on irc or jabber so we can try to get this thing resolved? (jabber@hboeck.de or hanno on freenode)
Comment 16 Giacomo Perale 2006-10-11 14:39:43 UTC
Tomorrow I should be able to hang on IRC, I hope. By chance today I stumbled on this thread on debian-x: http://www.mail-archive.com/debian-x@lists.debian.org/msg51055.html. Apparently the "02" patch doesn't make so much difference, and more importantly, someone is working on making the patches EXA-friendly. You should contact them, I think.
Comment 17 Joshua Baergen (RETIRED) gentoo-dev 2006-10-13 15:56:48 UTC
AIGLX patches are now only applied with USE="aiglx".  Thanks for the report.
Comment 18 Wolf Giesen (RETIRED) gentoo-dev 2006-10-17 01:46:51 UTC
Interestingly enough, I have the exact _opposite_ behaviour. Since -r1 hid the patches behind "aiglx", my Composite (with EXA) is slow as molasses. I am on the "radeon" driver with a X700 pro. I had to enable "aiglx" now to get unsluggish behaviour. Maybe I am missing the big point?!
Comment 19 Joshua Baergen (RETIRED) gentoo-dev 2006-10-17 16:00:50 UTC
Perhaps try re-building your driver X and see if that fixes it.
Comment 20 Wolf Giesen (RETIRED) gentoo-dev 2006-10-17 16:44:58 UTC
Why? I added the patches (in like adding aiglx for the new ebuild) and it's fine again ...
Comment 21 Joshua Baergen (RETIRED) gentoo-dev 2006-10-17 18:35:08 UTC
I mean that you should try rebuilding the driver without the patches and see if you resolve your speed problem that way.  You shouldn't have to have the patches for decent EXA support.
Comment 22 Alfie Parthum 2006-10-29 23:22:39 UTC
(In reply to comment #19)
> I mean that you should try rebuilding the driver without the patches and see if
> you resolve your speed problem that way.  You shouldn't have to have the
> patches for decent EXA support.
> 

Well, for me, it runs like _butt_ without the patches.  And with the patches, it crashes (see bug #151666). 
Comment 23 Wolf Giesen (RETIRED) gentoo-dev 2006-10-29 23:31:34 UTC
(In reply to comment #19)
> I mean that you should try rebuilding the driver without the patches and see if
> you resolve your speed problem that way.  You shouldn't have to have the
> patches for decent EXA support.

I may seem a bit dumb here, but since the patches apply to xorg-server, not  x11-drivers/xf86-video-ati, what exactly do you suggest? It's not really urgent anymore since it works again with USE="aiglx", but interesting nevertheless.
Comment 24 Joshua Baergen (RETIRED) gentoo-dev 2006-11-05 11:53:23 UTC
(In reply to comment #21)
> I may seem a bit dumb here, but since the patches apply to xorg-server, not 
> x11-drivers/xf86-video-ati, what exactly do you suggest? It's not really urgent
> anymore since it works again with USE="aiglx", but interesting nevertheless.
> 

My thought was that the patches were changing ABI somehow, meaning that the driver would have to be rebuilt against the server to fix the issue.  I agree that it's not a huge deal since it's functioning now.
Comment 25 Hanno Böck gentoo-dev 2006-11-30 13:18:23 UTC
Reporter, can you have a look at the patch on bug #151666 together with all aiglx-patches and see if that helps?
If exa runs fine with it then we could get rid of the aiglx-flag and apply the aiglx-patches always.
Comment 26 Giacomo Perale 2006-11-30 14:11:12 UTC
(In reply to comment #23)
> Reporter, can you have a look at the patch on bug #151666 together with all
> aiglx-patches and see if that helps?
> If exa runs fine with it then we could get rid of the aiglx-flag and apply the
> aiglx-patches always.
> 

I'm sorry but I can't help anymore with this bug, I recently upgraded my motherboard/cpu and I had to buy a new PCI-E videocard to replace my old AGP card
Comment 27 Joshua Baergen (RETIRED) gentoo-dev 2006-12-06 19:43:33 UTC
There's not really much evidence for or against these patches, and I believe they're all in the mainline now in some form.  With any luck, the aiglx USE flag will be gone in X 7.2.