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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glcompmgr.c
Type: text/x-csrc
Size: 29304 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/compiz/attachments/20060706/366115c0/glcompmgr-0001.c
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glcompmgr.c
Type: text/x-csrc
Size: 29304 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/compiz/attachments/20060706/2699bfac/glcompmgr-0001.c