Latest Xgl code

[David Reveman]

Hey everyone,

my latest Xgl code is now available in a tarboll from here:

http://www.freedesktop.org/~davidr/

I'd like to get this code into freedesktop CVS asap. I suggest that we
put it in a xgl module for now as I'm guessing that it'll take some time
before everything can be merged into Xorg and I don't want to spend any
time merging the code back into the kdrive tree.


CHANGES

Compared to the xserver module code in freedesktop CVS a lot have
changed. The new code contains an uncounted number of bug fixes, some
major restructuring and a few additional features.

The restructuring was necessary for Xgl's GLX support to work on
anything but the proprietary nvidia driver. Basically there's now an Xgl
binary and the window system specific code is dynamically loaded.

E.g. when running on GLX, libglx.so and libglcore.so modules for GLX
support in Xgl are first loaded using RTLD_NOW and RTLD_LOCAL flags. Xgl
then loads the libxglx.so module using RTLD_GLOBAL flag (as dri drivers
need that). Symbols in libglx and libglcore must be resolved before the
libxglx module is loaded as we don't wont symbols in these modules to be
resolved to anything in the libxglx module or any library linked to
libxglx, hence the RTLD_NOW flag. RTLD_LOCAL flag as when later loading
libxglx no symbols should be resolved to values in libglx or libglcore.

XVideo extension is supported and it's using the YUV surface support in
CVS version of glitz (requires GL_ARB_fragment_program). Only scaling
and conversion of YV12 colorspace is accelerated so far but it's not
hard to add support for additional colorspaces. Thanks to Matthias Hopf
for much of the implementation.

The XVideo ddx implementation in Xgl is very minimal, basically what
I've done is to add internal picture formats for YUV data so other than
some common initialization code the Xgl XV code basically contains a
call to SetPictureTransform and CompositePicture. Software fall-backs
are handled by fb-layer. Right now, it works but is dead slow. My idea
is that we should add some highly optimized code-paths for this and
compositing of normal pictures would also benefit form the fast scaling.

Xgl can now accelerate compositing of gradient pictures.

The libxglx module (Xglx before) is more functional now. It includes XKB
and RANDR support. It even includes some Xorg server wrapper code so
that when running Xgl without an X server present it can launch an Xorg
server and run Xgl fullscreen on it.


COMPOSITING MANAGER AND DRI DRIVERS

With the right options passed to Xgl you can run xcompmgr fully
accelerated, however you'll need ati's or nvidia's proprietary driver
for that.

You should be using an OpenGL compositing manager as it can run fully
accelerated even on dri drivers. I've been working on an OpenGL
compositing manager named compiz but I'm not ready to release the code
for it yet. I'm aiming for a release at XDevConf in February.

The DRI drivers needs some tweaks for a GL compositing manager to
perform well on them. What's missing is fast CopyPixel from back buffer
to front buffer. The attached patch was all I did to get the r200 driver
working. There's probably a bunch of checks missing for that patch to be
complete but you get the idea, just adding a fast CopyPixel path for
this specific case to a DRI driver and it should be working quite well
with Xgl and a well written GL compositing manager.


GETTING IT INTO XORG

glx and glcore in Xgl's X server tree contains a lot of code that is
necessary for GLX support in Xgl. We might need to rework a few of these
things to get it all into the Xorg tree.

fb code in Xgl's X server tree contains a few bug fixes for negative
stride to work correctly, some gradient fixes and fbCompositeGeneral
improvements which I've sent patches for to the cairo list a few months
back. fb also contains code for fetching pixels from YUV pictures (used
for XVideo software fall-back).

Xgl also needs the glyph privates I've had in kdrive tree for some time.
Eric Anholt has already sent a patch for this to the Xorg list.

Everyone is welcome to help out with getting the code into Xorg.


TEXTURE FROM PIXMAP

The GLX_MESA_render_texture implementation in Xgl can be used by a GLX
client for binding a pixmap to a texture object but it will soon be
replaced by an implementation of GLX_EXT_texture_from_pixmap, which is
pretty much the same thing. Until then GLX_MESA_render_texture will be
supported and I've attached the two patches needed for support in mesa's
indirect rendering code.


Happy new year,

-David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r200-copy-pixels-1.patch
Type: text/x-patch
Size: 2741 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060102/9a0ba716/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesa-glx-x11-get-drawable-attribs-fix-1.diff
Type: text/x-patch
Size: 1866 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060102/9a0ba716/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesa-glx-x11-render-texture-5.diff
Type: text/x-patch
Size: 3247 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060102/9a0ba716/attachment-0002.bin>