AIGLX, metacity, nvidia and Xgl
Anders Storsveen
wakko at generation.no
Tue Feb 28 03:16:20 PST 2006
David Reveman wrote:
> I've been getting a lot of mail from people asking me about my thoughts
> on AIGLX, the GL compositing work being done on metacity and nvidia's
> xdevconf paper. Instead of replying to everyone individually, I though
> I'd send a mail to the Xorg list.
>
> AIGLX [1]. It's great that we finally have accelerated indirect GLX
> working in the xfree86 ddx, something that we should have had many years
> ago. And with texture-from-pixmap support it should work well with
> compiz, I like that. The DRI driver requirements for Xgl and AIGLX are
> very similar so both Xgl and AIGLX will benefit from DRI driver work
> being done for one of them.
>
> Nvidia's paper [2] on why they don't think X on OpenGL is the best way
> to go is not a huge surprise to me. Xgl will work equally good across
> drivers, without requiring high-quality X drivers from all the vendors.
> In that way Xgl "levels the playing field" for hardware vendors. Nvidia
> already has good drivers with some functionality that it will take a
> while before Xgl can support. Compiz will work fine on Xorg with the
> nvidia driver once they release a version with the texture-from-pixmap
> support Xgl already got. But nvidia isn't the only hardware vendor on
> the market, and we want the X desktop experience to be as rich as
> possible for everyone.
>
> An important goal with X on OpenGL is to make it easier for X to keep up
> with the advances in graphics hardware. Eliminating the custom 2D
> acceleration code will reduce the development burden and make this
> easier. This can probably be achieved through AIGLX as well, I know that
> the people working on AIGLX have discussed putting some of the
> acceleration code I have in Xgl inside Xorg with AIGLX and that would be
> a step in that direction. However, I strongly believe that going all the
> way to an X server completely on top of the OpenGL API is the best
> solution in the long run.
>
> I think the arguments made by nvidia to why X on OpenGL would be worse
> than the current driver architecture can be debated on until forever. I
> think it all boils down to if we want put some more effort to it and
> take the big scary step to something new or if we want to stick to the
> old well known. Not too surprising, we have people who are in favor of
> both and we'll likely have development being done on both, which I don't
> think is that bad after all.
>
> So far I haven't heard a single argument for why X on OpenGL is a a bad
> idea other than that it's a big step and a lot of work will have to be
> done. If that would stop me from working on Xgl, I wouldn't have started
> working on it in the first place.
>
> Except the fact that it might slow down development of Xgl a little, I
> think that both AIGLX and nvidia's plan to support texture-from-pixmap
> are really good things that will make the X desktop better in the
> near future.
>
> I'm a little bit concerned about the work being done on GL compositing
> in metacity. During the first couple of months when I was experimenting
> with GL compositing on Xgl I had similar plans but after a few months I
> realized that starting from scratch and trying to reuse as much code as
> possible was the best idea. Others might be able to do a better job than
> me on figuring out how to extend metacity but I think it's to early to
> tell as the people working on metacity that I talked to at xdevconf
> didn't seem to be aware of issues I'm solving by not using an ordinary
> window manager like metacity for compositing. An important reason to why
> I favor compiz over metacity is that it works with other desktop
> environments than gnome. I definitely don't want all these effects that
> people are starting to write to only be usable on one desktop.
>
Don't you think when compiz get wider support, like good compiz
integration in kde, that kde devs and community and other wm-communities
will develop on it. And that should give compiz the "upper hand" when it
comes to development, and metacity would see that copying everything
from compiz is stupid and then switch to utilizing compiz too?
> I don't like a compiz/metacity split but I'm not sure what we can do
> here. I'll continue to reuse metacity code in compiz as plugins and I'll
> have a look at libcm asap and consider the possibility of integrating it
> with compiz somehow.
>
>
> There seems to be a lot of people confused about this, so to clarify
> things, I also like to respond to this paragraph from the fedora aiglx
> page:
>
> "We've been working on the AIGLX code for a some time with the
> community, which is in direct contrast with the way that XGL was
> developed. XGL spent the last few months of its development behind
> closed doors and was dropped on the community as a finished solution.
> Unfortunately, it wasn't peer reviewed during its development process,
> and its architecture doesn't sit well with a lot of people."
>
> I've been developing Xgl in the open since November 2004. Only the last
> few months have been behind closed doors. I can agree that this wasn't
> the best thing but no architectural changes have been made during this
> period, just a lot of hard work implementing missing functionality,
> tracking down and fixing bugs in xgl and various other places in the x
> server tree. We didn't drop a finished solution, we dropped a much
> improved version, that's all.
>
> At the time the decision was made to stop push things into CVS for a
> while, no one except me was really contributing to the project and the
> testing and bug reports we got from the community didn't give us much.
> If we had to make architectural changes or if the interest in
> contributing to the project got bigger, the idea was always to open
> development again.
>
> -David
>
>
> [1] http://fedoraproject.org/wiki/RenderingProject/aiglx
> [2] http://developer.nvidia.com/object/xdevconf_2006_presentations.html
>
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
More information about the xorg
mailing list