A patch to make XGL much faster!

[stjepan]

I got sick of slow widow showing in XGL, slow animations and slow resizing. Then I emailed David about the problem. He says he can fix it with a "dirty hack", which aslo AIGLX uses. He made a little patch. I tried it and guess what - XGL got so much faster, animations are very smooth now, resizing is very fast. I'll never use AIGLX again :)!

The patch:
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -486,12 +486,24 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int h)

ValidateGC(&pPixmap->drawable, pGC);
dixChangeGC (serverClient, pGC, GCSubwindowMode, &val, NULL);
+
+#if 1 /* ugly hack to avoid frame buffer reads */
+ val = 0;
+ dixChangeGC (serverClient, pGC, GCForeground, &val, NULL);
+
+ {
+ xRectangle rect = { 0, 0, w, h };
+ (*pGC->ops->PolyFillRect) (&pPixmap->drawable, pGC, 1, &rect);
+ }
+#else
(*pGC->ops->CopyArea) (&pParent->drawable,
&pPixmap->drawable,
pGC,
x - pParent->drawable.x,
y - pParent->drawable.y,
w, h, 0, 0);
+#endif
+
FreeScratchGC (pGC);
}
return pPixmap;



stjepan

[julio]

I got sick of slow widow showing in XGL, slow animations and slow resizing. Then I emailed David about the problem. He says he can fix it with a "dirty hack", which aslo AIGLX uses.
Would you know why is it a "dirty hack" ?
That probably means that something nasty can happen anytime, no ?

[stjepan]

No, nothing nasty will happen. AIGLX uses this "dirty and ugly" hack too :). (Note that AIGLX is officially in Xorg 7.1 and higher!)

This is what David said yesterday:
it's likely framebuffer reads or that fglrx got a slower
memory manager. framebuffer reads are even more of a problem in aiglx
but I know that they have an ugly hack to avoid them. I can write a
similar hack to xgl which will likely improve performance a lot but this
kind of hack makes the server render incorrect results in one particular
case. However, most people don't even notice this so the increased
performance might be worth it.

Today he made a patch and he said this:
It's slow because drivers/hardware is slow so fixing it is not easy or
even possible by me if it's a proprietary driver. I can workaround the
issue with an ugly hack, like redhat has done in aiglx. I'm not too
happy about creating ugly hacks for issues that should be fixed
elsewhere but this one seem to be making a big difference so I'll likely
get it done sometime soon.

[julio]

No, nothing nasty will happen. AIGLX uses this "dirty and ugly" hack too :). (Note that AIGLX is officially in Xorg 7.1 and higher!)
Ok :)
This is what David said yesterday:
Where did he say that ? I did not see anything on the mailing list ?
it's likely framebuffer reads or that fglrx got a slower
memory manager. framebuffer reads are even more of a problem in aiglx
but I know that they have an ugly hack to avoid them. I can write a
similar hack to xgl which will likely improve performance a lot but this
kind of hack makes the server render incorrect results in one particular
case. However, most people don't even notice this so the increased
performance might be worth it.
I'm very curious what this one particular case is ! Do you know where I may find information about it ?

It's slow because drivers/hardware is slow so fixing it is not easy or
even possible by me if it's a proprietary driver. I can workaround the
issue with an ugly hack, like redhat has done in aiglx. I'm not too
happy about creating ugly hacks for issues that should be fixed
elsewhere but this one seem to be making a big difference so I'll likely
get it done sometime soon.
Can't wait to have it ;)

[stjepan]

I'm very curious what this one particular case is ! Do you know where I may find information about it ?
We've talked via email, privately.

Can't wait to have it ;)
I have it right now :)
Just patch your XGL and you'll have it.

[stjepan]

Danimoth included this patch in his XGL packs for ArchLinux.
If you want to use his repository, see this: http://wiki.archlinux.org/index.php/Xgl#From_a_repo_.28easier.29

The patch is in xgl-git-20061222 package and higher versions.

[FunkyM]

openSuSe 10.2 Package including this patch here (http://rpm.sukimashita.com/10.2/i586/xgl-git_070104-8.1.i586.rpm).

It seems to be significantly faster in resizing and other stuff where bigger areas got redrawn. The downside is that you occasionaly see black flickering and black parts in windows (due to missing the extra redraw) but that happens really rarely so this is absolutely useable.

UPDATE: Removed as the patch is included in the newer official packages by default.

[chrisxkelley]

Hey guys, sorry to bring an old(ish) thread back from the dead, but I'm looking to improve compiz on my computer and would like to try this, but have no idea where to start. Do I need to recompile compiz with this code? If so, how can I go about doing that?

Sorry for the noob -- I'm new to compiz but definately not new to linux :)


Thanks,
Chris

[RYX]

Hi Chris!

You will not need to compile compiz, but Xgl. The patch is for Xgl, the opengl-based xserver. I think you can get it on freedesktop.org ... (after re-reading this thread I think about trying it, too :D)

:)

[maniac]

Hi Chris!

You will not need to compile compiz, but Xgl. The patch is for Xgl, the opengl-based xserver. I think you can get it on freedesktop.org ... (after re-reading this thread I think about trying it, too :D)

:)
It's worth trying, it really produces a large speedup :)
There may also be source packages for the distro of your choice; just google around a bit ;) ... For FC6 (as an example), they can be found here (http://files.damaestro.us/xgl/).

[jinchuriki]

Hi guys, i'm using compiz 0.0.10 with xgl on fglrx driver for ATI. Do i need this patch? or this patch is already included in the version that i'm using?

[dcherryholmes]

I am running Ubuntu 7.10/fglrx/xgl. I tried to apply the patch in this thread, but something seems to be going wrong. Here's my output. I don't produce a .deb. Does anyone have any idea what's wrong?

xxxxxx@yyyyyy:~/src/packages/xserver-xgl-1.1.99.1~git20070727$ patch -p1 < /home/dmc/src/xgl.patch
patching file composite/compalloc.c

xxxxxx@yyyyyy:~/src/packages/xserver-xgl-1.1.99.1~git20070727$ fakeroot dpkg-buildpackage -us -uc
dpkg-buildpackage: source package is xserver-xgl
dpkg-buildpackage: source version is 1:1.1.99.1~git20070727-0ubuntu3
dpkg-buildpackage: source changed by Christopher James Halse Rogers <raof@ubuntu.com>
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 1.1.99.1~git20070727-0ubuntu3
debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
if [ -f Makefile ] ; then /usr/bin/make distclean ; fi
# Remove the mesa symlinks generated on configure
find GL -type l -delete
dh_clean
dpatch deapply-all
02-add-missing-gl-struct not applied to ./ .
01-compalloc-faster not applied to ./ .
rm -rf patch-stamp patch-stampT debian/patched
dpkg-source -b xserver-xgl-1.1.99.1~git20070727
dpkg-source: building xserver-xgl using existing xserver-xgl_1.1.99.1~git20070727.orig.tar.gz
dpkg-source: building xserver-xgl in xserver-xgl_1.1.99.1~git20070727-0ubuntu3.diff.gz
dpkg-source: warning: executable mode 0755 of 'debian/patches/02-add-missing-gl-struct.dpatch' will not be represented in diff
dpkg-source: warning: executable mode 0755 of 'debian/patches/01-compalloc-faster.dpatch' will not be represented in diff
dpkg-source: building xserver-xgl in xserver-xgl_1.1.99.1~git20070727-0ubuntu3.dsc
debian/rules build
test -d debian/patched || install -d debian/patched
dpatch apply-all
applying patch 01-compalloc-faster to ./ ... failed.
make: *** [patch-stamp] Error 1

[some-guy]

That patch is enabled by default in xgl now

[dcherryholmes]

That patch is enabled by default in xgl now

Ah, good to know. Then I wonder why Xgl is freezing my desktop if I resize a window? Minimize, scrolling, and everything else works fine.