Is xgl considered dead?

[David Reveman]

On Thu, 2007-04-12 at 01:08 +0200, Hanno Böck wrote: 
> Hi,
> 
> I wanted to raise up this question because I recently got a request if we plan 
> to add xgl to gentoo.
> 
> xgl-development seems to be pretty much dead. There haven't been much commits 
> lately and as far as I can see, just about everything in the past months only 
> were compile-fixes.

It's definitely not dead. There's a lot of things that I want to improve
but I haven't had the time and before I do more work on it I'd like to
get it merged to head.

All the new glucose work can be considered xgl development but I guess
you're interested in knowing whether you should include an ebuild for
the Xgl binary or not. There's currently only one backend module for Xgl
that is useful and it's the xglx module, which makes it possible to run
xgl on top of an existing X server. The xegl backend is one way to get
xgl running in a stand-alone server. xegl is a great idea but it would
force us to re-implement a lot of things in the xorg driver model before
it could be a full replacement and it doesn't make sense to do this
unless everyone thinks it's the way to go. Glucose, is another way to
get xgl running in a stand-alone server. It makes it possible to run xgl
in the existing xorg driver model and it's more likely the future but
you don't have to care much about that as including this is likely just
going to be a use-flag for xorg-server ebuild.

Xgl with xglx backend was never supposed to be a final solution but it
works well for a lot of people as a replacement for just running the
xorg server and it's awesome for development/debugging/testing of xgl
architecture and OpenGL drivers. I don't see any good reason why you
shouldn't included it in gentoo, especially once it's merged into head.

> Pretty much everyone suggests to prefer aiglx. Nvidia has their own 
> tfp-implementation.

Please understand that xgl is not just a tfp alternative. It's a new
acceleration architecture layered on top of OpenGL. tfp happens to work
really well in this architecture and as more acceleration is added to
xgl and provided by drivers, the more efficient tfp will get. 

> 
> 
> xegl, which was once announced as the future of xgl, is even more dead and 
> probably not running anywhere.

See above.

> 
> Now, from what I see, there are two reasons left why someone might want to 
> have xgl:
> a) if you rely on proprietary ati-driver
> b) aiglx doesn't allow transformation of xv and gl-apps
> 
> For b), I'd be interested what would be needed to make that working on aiglx. 
> For a) there's probably not much one can do beside improving free r300-code.
> 
> Anyway, to David Reveman, maybe you wanna give a statement what your plans for 
> xgl are.

It's simple. I'll work on getting it merged into head once I have time.
After that I'd like to get everything that's currently working with
xgl-xglx also working with glucose. 

- David