Re: Why run xserver on the OpenGL API?

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

> Well that is a little different to what was originally proposed. The
> original proposal was to make X live on top of OpenGL proper and migrate
> apps and toolkits over to using OpenGL only for all rendering. IMHO that is
> a bad idea because OpenGL is pretty bad at basic 2D stuff.

I think there have been several different ideas floating about on the 
list; I've tried to keep my own interests clearly focused on making the X 
server more easily ported to new and existing hardware by taking advantage 
of the GL device abstraction (even if we have to break it a bit in the 
process).

> However if the 'device driver' layer is basically an extended OpenGL back 
> end with extensions for direct framebuffer access and some basic 2D 
> operations, then that is a different story altogether.

I don't think there are any new accelerated functions needed in GL for core
2D operations; glCopyPixels is sufficient for CopyArea, and all we need
aside from that is FillRectangles.  There are a few interesting compositing
operation modifications that could accelerate bits of Render, and may in
fact be of some interest to 3D applications as well at some point.

Note that I'm not interested in some 2D subset of GL for hardware 
incapable of supporting full GL; that's not really helpful at all; 
creating a 2D subset and then carefully targeting the X server to that 
seems far more complicated than just defining a simple 2D-specific driver 
interface for cards that don't have 3D support.  I suspect you know of at
least on such interface.

> Having a function call FillRect() that the X server can call directly that
> goes direct to the hardware driver (even if the hardware driver implements
> it using the 3D engine), will be a lot more efficient than having to go
> through the entire OpenGL rendering pipeline before it gets to the hardware
> back end.

As far as I can tell, GL gets stuff out to the hardware plenty fast; 2D 
applications aren't hurting from that kind of performance limits today, 
and I'm not interested in optimizing things at this level until someone 
demonstrates a clear problem.  For hardware which can do GL, the pipeline 
is almost entirely executed in silicon; hardware which can't do GL isn't 
part of this solution space and doesn't matter.

> One thing to note to is that I have not yet figured out a way to 
> efficiently do a screen->screen BitBlt() operation using a hardware 3D 
> engine (especially via OpenGL 3D). Hence I do not believe 2D rendering 
> functionality will be going away anytime soon.

Is there something I don't understand about glCopyPixels?  I have to admit 
limited experience with OpenGL, having read through the various OpenGL 
specification versions doesn't really demonstrate what the system actually 
can do.

> If on the other hand the RENDER functions are implemented directly by a
> hardware driver using the 3D engine (as they are in the Matrox driver for
> instance) the performance will be significantly better than trying to push
> it all through the OpenGL rendering pipeline.

I doubt that performance on top of OpenGL will be measurably different 
from a "native" implementation, and given that we have to coordinate with 
the DRM in any case to get kernel support for DMA, IRQ and AGP memory 
space, it doesn't seem like there's any significant advantage to avoiding 
the small user-land cost of OpenGL api itself.  The benefit of using a 
standard API shouldn't be underestimated; there will not be any need to 
"port" the X server at all with this new mechanism, all that will be 
needed is to write a OpenGL driver and X will come for free.

And, if there are performance issues, we can create OpenGL extensions to 
address them; that's a great opportunity for driver vendors to add value 
:-)

As others have said, having OpenGL part of the standard desktop software 
environment will greatly improve the quality and performance of a wide 
range of applications; having X rely on OpenGL will both encourage people 
to improve OpenGL support while at the same time making it easier to do so.

-keith