[compiz] A simple accelerated GL compositor
I attach a simple GL based compositor that runs with the nVidia drivers for Xorg 7.0 and 7.1. These drivers support accelerated indirect GL, so this compositor does not need aiglx or Xgl. By keeping things simple, I have managed to identify and dodge some bugs in the nVidia Xcomposite support. I am currently testing the compositor with the ATI drivers. The compositor deliberately offers no eye candy (apart from alpha support) and should be completely invisible to the user when working correctly. I intend to concentrate on maximising the performance of this compositor. It uses Xcomposite 0.3 overlays under Xorg 7.1. Hopefully, the lessons learnt will be of use to compiz and metacity, since for 99% of the time their intended behaviour will be similarly unobtrusive. The compositor relies on glTexSubImage copies on damaged areas as a replacement for the absent glBindTexImage. The fastest speeds are obtained when the glTexSubImage copies are applied to a GLXPixmap reference to the Xcomposite Pixmap. However, this approach crashes when windows are unmapped or sized due to a bug in the nVidia drivers. The crashes may be avoided by discarding the GLXPixmap references immediately after the glTexSubImage copies, but this is horrendously slow. I have raised this issue with James and he has added it to nVidia bug tracking system. I understand from Soren that there are problems with GLXPixmap references under the ATI drivers as well and once I have tested the compositor against their drivers I may be able to raise the same issue with them. The fastest means of avoiding the crashes is to perform an XCopyArea on the damaged areas into a separate "copy buffer" Pixmap and then perform the glTexSubImage copies out of this Pixmap. I have yet to devise any faster solution that would avoid crashes from non override_redirect windows. Unless I use a copy buffer Pixmap on my nVidia 6150 GPU then I find that GLX client windows freeze under glcompmgr (this problem occurs with rawhide Xorg 7.0 and Xorg 7.1 in both the x86_64 and i386 builds). I understand from James that he does not encounter these freezes on his platform. Therefore, I would be interested in learning of any other platforms that are effected by this problem and in any ideas about what might be causing it. My intial throught was that the nVidia indirect GLX implementation might be having problems with shared drawables when an indirect glTexSubImage request is received from the compositor context between certain indirect render requests from the client context (eg glBegin / glEnd). However, James has dismissed this particular explanation on the grounds that GLX should not suffer synchronisation problems providing the compositor has a server grab (as it does in the attached code). The sources should build reasonably easily against the nVidia drivers. The code does not try anything too special with GLX/GL, so it should build and work on other GLX platforms as well. The X setup will no doubt need some tweaking to get things working. The setup up for the nvidia drivers is as follows: Xorg 7.1 command line: Xorg -ignoreABI # ABI out of sync on Xorg 7.1 xorg.conf requirements: Section "Screen" Option "HWCursor" "On" # glcompmgr broken with SW cursor Option "AddARGBGLXVisuals" "True" # nVidia alpha voodoo Option "RenderAccel" "Off" # nVidia broken on Xorg 7.1 EndSection Section "Extensions" Option "Composite" "Enable" EndSection I am interested in any problems that anyone finds in building or running this code on any platform. Felix /* * glcompmgr - a simple accelerated GL compositor focusing on speed. * * Requires: * Accelerated compositing (Xorg >= 7.0 and accelerated GLX drivers) * * Supports: * Any window manager. * Alpha blending, opacity property, shaped windows. * Xcomposite 0.3 overlays (Xorg >= 7.1). * * Trialed on: * nVidia 6150 GPU 1.0.87.62 drivers: * Xorg 7.0 (Fedora 5 x86_64) * Xorg 7.1 (Fedora Rawhide x86_64 & i686 / Xorg vanilla x86_64) * * Does NOT require: * GLX_EXT_texture_from_drawable, XRender * * Does NOT provide: * Eye candy. * * Make on nvidia GLX with: * gcc -I/usr/include/nvidia -L/usr/lib64/nvidia -L/usr/lib/nvidia \ * -lXcomposite -lXdamage -lX11 -lGL \ * `pkg-config --libs --cflags glib-2.0` glcompmgr.c * * Issues: * 1) Bug work arounds included for GLXPixmap failure on window unmap/resize. * a) COPY_BUFFER = 1 * Fastest performing fix. (glxgears speed around 60% of non-comp) * b) REFRESH_DRAWABLES = 1 * Slower, but simpler fix (glxgears speed around 20% of non-comp) * * Bug does not impede performance significantly. texture_from_drawable * extension will improve performance, but not hugely. * * 2) Some platforms encounter GL client freezes when COPY_BUFFER = 0. * Problem consistent over all tested GPU 6150 platforms, but not
[compiz] A simple accelerated GL compositor
I attach a simple GL based compositor that runs with the nVidia drivers for Xorg 7.0 and 7.1. These drivers support accelerated indirect GL, so this compositor does not need aiglx or Xgl. By keeping things simple, I have managed to identify and dodge some bugs in the nVidia Xcomposite support. I am currently testing the compositor with the ATI drivers. The compositor deliberately offers no eye candy (apart from alpha support) and should be completely invisible to the user when working correctly. I intend to concentrate on maximising the performance of this compositor. It uses Xcomposite 0.3 overlays under Xorg 7.1. Hopefully, the lessons learnt will be of use to compiz and metacity, since for 99% of the time their intended behaviour will be similarly unobtrusive. The compositor relies on glTexSubImage copies on damaged areas as a replacement for the absent glBindTexImage. The fastest speeds are obtained when the glTexSubImage copies are applied to a GLXPixmap reference to the Xcomposite Pixmap. However, this approach crashes when windows are unmapped or sized due to a bug in the nVidia drivers. The crashes may be avoided by discarding the GLXPixmap references immediately after the glTexSubImage copies, but this is horrendously slow. I have raised this issue with James and he has added it to nVidia bug tracking system. I understand from Soren that there are problems with GLXPixmap references under the ATI drivers as well and once I have tested the compositor against their drivers I may be able to raise the same issue with them. The fastest means of avoiding the crashes is to perform an XCopyArea on the damaged areas into a separate "copy buffer" Pixmap and then perform the glTexSubImage copies out of this Pixmap. I have yet to devise any faster solution that would avoid crashes from non override_redirect windows. Unless I use a copy buffer Pixmap on my nVidia 6150 GPU then I find that GLX client windows freeze under glcompmgr (this problem occurs with rawhide Xorg 7.0 and Xorg 7.1 in both the x86_64 and i386 builds). I understand from James that he does not encounter these freezes on his platform. Therefore, I would be interested in learning of any other platforms that are effected by this problem and in any ideas about what might be causing it. My intial throught was that the nVidia indirect GLX implementation might be having problems with shared drawables when an indirect glTexSubImage request is received from the compositor context between certain indirect render requests from the client context (eg glBegin / glEnd). However, James has dismissed this particular explanation on the grounds that GLX should not suffer synchronisation problems providing the compositor has a server grab (as it does in the attached code). The sources should build reasonably easily against the nVidia drivers. The code does not try anything too special with GLX/GL, so it should build and work on other GLX platforms as well. The X setup will no doubt need some tweaking to get things working. The setup up for the nvidia drivers is as follows: Xorg 7.1 command line: Xorg -ignoreABI # ABI out of sync on Xorg 7.1 xorg.conf requirements: Section "Screen" Option "HWCursor" "On" # glcompmgr broken with SW cursor Option "AddARGBGLXVisuals" "True" # nVidia alpha voodoo Option "RenderAccel" "Off" # nVidia broken on Xorg 7.1 EndSection Section "Extensions" Option "Composite" "Enable" EndSection I am interested in any problems that anyone finds in building or running this code on any platform. Felix /* * glcompmgr - a simple accelerated GL compositor focusing on speed. * * Requires: * Accelerated compositing (Xorg >= 7.0 and accelerated GLX drivers) * * Supports: * Any window manager. * Alpha blending, opacity property, shaped windows. * Xcomposite 0.3 overlays (Xorg >= 7.1). * * Trialed on: * nVidia 6150 GPU 1.0.87.62 drivers: * Xorg 7.0 (Fedora 5 x86_64) * Xorg 7.1 (Fedora Rawhide x86_64 & i686 / Xorg vanilla x86_64) * * Does NOT require: * GLX_EXT_texture_from_drawable, XRender * * Does NOT provide: * Eye candy. * * Make on nvidia GLX with: * gcc -I/usr/include/nvidia -L/usr/lib64/nvidia -L/usr/lib/nvidia \ * -lXcomposite -lXdamage -lX11 -lGL \ * `pkg-config --libs --cflags glib-2.0` glcompmgr.c * * Issues: * 1) Bug work arounds included for GLXPixmap failure on window unmap/resize. * a) COPY_BUFFER = 1 * Fastest performing fix. (glxgears speed around 60% of non-comp) * b) REFRESH_DRAWABLES = 1 * Slower, but simpler fix (glxgears speed around 20% of non-comp) * * Bug does not impede performance significantly. texture_from_drawable * extension will improve performance, but not hugely. * * 2) Some platforms encounter GL client freezes when COPY_BUFFER = 0. * Problem consistent over all tested GPU 6150 platforms, but not
