Getting to a GL based X server

[Jim Gettys]

On Thu, 2005-05-26 at 15:55 -0400, Jon Smirl wrote:
> On 5/25/05, Jim Gettys <Jim.Gettys at hp.com> wrote:
> > This is the crux of the issue: at what point do we "commit" to this
> > path?  I think most acknowledge that the redundant driver development is
> > costing us greatly, and it is pretty clear where the future is...
> 
> How can we arrive at a consensus (if we can?) that a GL based X server
> is the future?

I believe we may now have rough consensus on this point, between your
and Dave's prototyping work, though I'm not sure parts of the community
fully understood what was going on until quite recently (the confusion
between the GL work and the Linux driver mess having made things murky
for those outside of the Linux community).


> 
> Technically I don't see any problems building one. There are a few
> issues that aren't fully worked out but nothing that appears to be
> unsolvable. We already have Xglx as a demo and it works pretty well.
> In a little while Xegl will be ready and it will work without being
> nested in another Xserver. But Xglx and Xegl are demo vehicles and not
> production servers.

The big remaining issue with relatively unknown engineering costs is
memory management.  To my knowledge, we've not done any prototyping here
yet.  It is hard to "commit" without some scoping of this issue.

No one thinks this is insoluble: we just don't know how much work to
solve it yet.

> 
> I would argue that the sooner we can commit to something like this the
> better. For example the design of low end servers may change a lot if
> they go with software based OpenGL-ES running Xegl. The shift to Xgl
> may trigger the development of more OpenGL-ES stacks.
> 
> On the other side no one is going to take away the current server. If
> you have existing hardware it will continue to work with the current
> server. Depending on how modularization goes it may be possible to run
> both XAA and Xgl in the same server although it is not clear to me how
> DRI would work in the XAA case.
> 

Doesn't have to be the same server image, particularly after
modularization is complete.  One might argue that carrying too much
baggage forward will be a drag; there have been many ddx's in X's
history, and XAA is only one of them (though with very wide hardware
support).  And in fact, it is desirable that we have some reasonable
transition strategy, where we don't have too complex a system to test.

The issue is how to get there from here, and how to do a smooth
transition, which will certainly be longer than we'd like (it always
works that way), given the realities of having a user base to support
and available resources.  Most of the major open questions have been
closed, and if we can get a better handle on memory management, I think
the remaining nervousness will be reduced.  And as both the
modularization and cairo projects reach fruition and the market allows
for more investment, I believe more resources will become available over
the next 3-6 months.

				Regards,
					- Jim