Re: Why run xserver on the OpenGL API?

Keith Packard <[email protected]>
Newsgroups gmane.comp.freedesktop.xserver
Message-ID <[email protected]>
Around 20 o'clock on Nov 24, Jon Smirl wrote:

> 1) OEMs like NVidia/ATI have a very high level device driver API to do their
> optimizations below.

This seems like the most important feature; GL is plenty fast for 2D 
graphics of today, probably faster than we could reasonably expect vendors 
to bother accelerating just for X.  And, GL matches Render very nicely, so 
we'd suddenly move from Render sucking badly to Render going as fast as 
the card can run.

The main thing is to eliminate one of two separate pieces of code talking 
to the video hardware; giving total control over the acceleration code to 
one library is going to help stabilize hardware support.

> 2) With OpenGL under xserver all windows will always have the OpenGL API
> available. xlib can slowly phased out. OpenGL is a well designed API suitable of
> the next 10 years. 

I'm not sure this is desirable; with the 2D Render API sitting atop GL 
where GL is available, having apps use that API will still let us run 
reasonably fast software implementations, Mesa still has a lot of 
overhead, especially on machines with limited CPU performance (or a lack 
of an FPU, like arm machines).

> 4) 90% of new hardware is 3D capable today. In 10 years year 100% will be. The
> bandwidth demands of a display in 2010 with a 10K by 10k floating point
> framebuffer on a GPU will be enormous. 

Perhaps in the PC market, but not in the rest of the Linux market.  Using 
GL is clearly the right X backend for the desktop market; one driver, 
accelerated compositing and trivial X server architecture.  Seems like a 
huge win.

Of course, I'm hoping to see cairo become an important graphics API, and 
cairo already has Render and GL backends, so it's pretty much irrelevant 
what backend is actually available.

-keith
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.