Re: Why run xserver on the OpenGL API?

Keith Packard <[email protected]> wrote:

> Around 12 o'clock on Nov 25, "Kendall Bennett" wrote:
> 
> > There is also no reason why you cannot make the existing 2D API's work
> > on top of the new back end 3D rendering engine as well. Choice of the
> > API you want to use is good, as long as the back end implementation does
> > not need to be different (one of the primary reasons our SNAP drivers
> > work so well; the back end is identical no matter whether you are using
> > it for Windows, OS/2 or Linux).
> 
> I thought that was implicit in the plan to write a GL backend for
> the existing X server rendering infrastructure.  The idea is that
> all core X and Render acceleration would be done with GL function
> calls, and that for ease of porting the existing code, a dumb frame
> buffer could be accessed where necessary. 

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.

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. The basic 2D 
operations should remain and be exported via extensions or something from 
the OpenGL back end - in the case of non-3D hardware they can be done 
using the 2D engine as we do it today. In the case of 3D hardware, they 
could be done using the 3D engine. 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.

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.

> Not that the core graphics need a lot of acceleration these days;
> I get by quite nicely with only copyarea and fillrectangles
> accelerated at all. 

True, 80% of the performance comes from those two functions.

> Render, on the other hand, could really benefit from most of the GL
> pixel pipeline... 

Right, but to get to the pixel pipeline you need to also go through the 
geometry pipeline and all the rest of the cruft associated with that. Yet 
another performance bottleneck. 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.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~