Re: Why run xserver on the OpenGL API?

Around 17 o'clock on Nov 25, "Kendall Bennett" wrote:

> If you assume a GL back end already exists for new hardware, then sure,
> that makes it more portable. But if the said back end does not exist,
> building an X server that can at least do 2D will be a lot more complicated
> since now you need to deal with an entire OpenGL pipeline implementation.

Fortunately, X needn't target only a single back end, so systems without 
OpenGL would not need to implement it simply to support X.  But, I would 
hope that most new graphics chips do come with OpenGL drivers; eliminating
the need to also write a 2D driver may encourage vendors to support OpenGL 
from the start.

> I wasn't suggesting a subset for 2D only cards, just that you would need 
> a way to ensure that 2D only cards *can* accelerate all of the 2D 
> operations used by the X server easily.

Sure, that's easy to do with Snap or other existing 2D acceleration
infrastructure.  If a driver isn't going to support OpenGL, then this whole
thread isn't relevant (except perhaps insomuch as it encourages the driver 
vendor to do OpenGL instead of a 2D driver).

> I am not entirely sure the performance would be up to snuff, but maybe it
> would be good enough at least initially. Of course we will never know until
> we try it in practice and find out where the hot spots really exist ;-)

Yup.  I'm willing to let the OpenGL folks show us just how fast they can 
get pixels moving on a modern graphics card and let us humble 2D window 
system developers get on with life back up in the land of device 
independent code.  From what I've seen of the DRI performance on modern 
Radeon cards, I have no worries on this score.

> glCopyPixels will do just fine for a screen->screen blit operation, but 
> my point is that glCopyPixels is *not* implemented as part of the 3D 
> engine, at least I am not aware of it being done that way. It just copies 
> blocks of data around on the screen, and in the end boils down to a basic 
> 2D BitBlt operation.

Fortunately, a 2D bitblt operation is precisely what we want.  As long as
the OpenGL *API* is sufficient for building X on top, I think we can expect
specific significant performance issues to be solved in the underlying
implementation during the X server transition process.

> Hey, you just might convert me yet! 8-P.

The proof of this architecture will need to wait for an actual
implementation.  That's another good reason to try and get something
running relatively quickly; we'd get to see if it would actually work, or
at least start finding out what needs to change to make it actually work.

-keith