Xegl lives!

Jim Gettys Jim.Gettys at hp.com
Wed May 25 08:12:20 PDT 2005


> But I agree with Jon that the redundant driver development is costing us
> time, and that OpenGL- and D3D-capable hardware is what the rest of the
> world is targeting across the entire range of devices.  I'd add that the
> "3D" APIs are still acquiring new functionality, and much of it may be
> valuable for "2D" graphics beyond what we're considering today; it's
> harder to take advantage of that stuff if we've gone down a different
> API path.
> 


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.

I would argue that the order needs to be:

	1) Modularization of X distribution/completion of Cairo
	2) GL based server.

In this order.

Once we're modularized, and many of our toolkits are no longer stuck
with core X rendering, then we take on the transition to GL based
servers.

>From what I can tell from conversations with ATI and NVidia, we'll be
seeing GL implementations with FBO support during the second half of
this year.

The point of this order is that we need to get the application
developer's away from core X rendering ASAP, and by doing the
modularization work now, we can start plugging in different server
implementations with much less trouble.

This also gets us enough time/experience to know where the traps are in
the GL approach.

>From all I've seen, there are two major issues left in GL based
solutions:

	a) memory management.  With composite, we'll pay a heavy price for not
having pixels in the right place in the right time, and be putting major
pressure on off screen memory.  We have no experience here, and I expect
we're going to need substantial experimentation to "get it right".
	b) interactivity: a GL program can cause the GPU to stay busy for
extended periods.  How do we address this issue?

We must have solutions for both a) and b) to successfully make a
transition to GL based servers.

This does beg the question: how to get more resources applied to the GL
branch, to get answers to these questions ASAP.  We clearly don't have
enough resources to apply right now; there may be others out there from
what I can tell who can contribute resources, though they have not
exposed their cards much so far.

				Regards,
					- Jim





More information about the dri-egl mailing list