AIGLX, metacity, nvidia and Xgl

[Anders Storsveen]

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.
>   
Nvidia talks about the problems of implementing vendor-specific functions:

"Goals 6 and 7
Goals 6 and 7 can be considered together; they both focus on giving
vendors the flexibility to
support features like OpenGL, TwinView/MergedFB, Quad-Buffered Stereo,
Workstation
Overlays, etc. Features such as these are possible within the current
loadable driver
framework; this is evident from the earlier mentioned examples of
vendors who have
provided these features. However, the X-on-OpenGL model poses some
difficult problems
for supporting existing and future advanced features.
For example, consider hardware-accelerated direct-rendering OpenGL. To
support a directrendering
client within X, a server-side component must coordinate with the
direct-rendering
client library to:
􀂉 Propagate data from the server to the client about the drawable's
geometry, clips, and
other attributes.
􀂉 Manage synchronization between the server and the client such that
the client's rendering
arrives in the correct place at the correct time.
Please refer to [16] for more details on how a direct-rendering client
interacts with the X
window system.
With the X-on-OpenGL model there would be no X driver, just a
stand-alone OpenGL
implementation. It is not clear in this model how data propagation or
synchronization would
be managed, or who would manage it.
Using the same OpenGL library from both OpenGL clients and the
X-on-OpenGL server
may impose undesirable requirements on the OpenGL implementer. For
example, special
communication between the X-on-OpenGL DDX and the OpenGL implementation
would
be necessary for the following reasons:
􀂉 The OpenGL implementation must determine if it is running within the
X server or
within the OpenGL client.
􀂉 If the OpenGL implementation is running within the X server, the OpenGL
implementation must manage the data propagation to and synchronization
with the
instance of the OpenGL library running in the direct-rendering OpenGL client
applications.
How would vendors provide vendor-specific features like TwinView,
FrameLock, Quad-
Buffered Stereo, and Workstation Overlays, within the X-on-OpenGL model?
Features such
as these largely depend on coordination between the X server and the
OpenGL client library.
In the best case, providing the same level of functionality as is
available with current NVIDIA
drivers will require a major effort to re-implement large portions of
the support directly in
Xgl, and negotiate numerous backdoors between Xgl and the stand-alone
OpenGL driver. In
the worst case, some of the features provided by existing drivers, like
Workstation Overlays
and Quad-Buffered Stereo, may not be possible at all with Xgl."

What comments do you have on this? Most importantly hw accelerated
direct rendering, but also the vendors-specific feature problem.
Is nvidia lying too us, or is this hard/impossible to work out?
> 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.
>
> 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
>