Re: Why run xserver on the OpenGL API?

Keith Packard <[email protected]> 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).

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.

> 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 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. Bear in mind that although most 
hardware today has 3D capabilities, for the Open Source community the 
cards may as well be 2D only if the 3D specs are not available. Even in 
that case, I am sure you still want to at least have fast 2D on such a 
card, rather than have everything go through a slow software OpenGL 
engine.

> I suspect you know of at least one such interface. 

Naturally ;-)

> > 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. 

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 
;-)

> > 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. 

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.

Someone mentioned that they thought 2D would go away and be replaced 
completely by 3D, but unless there is a way to render a triangle to a 
desstination buffer and also use the destination buffer as a source 
testure map, and make sure the overlapping regions are properly taken 
care of, you cannot use the 3D engine to implement a screen->screen 
BitBlt function. If there is a way to do this I am all ears, because I 
was trying to figure out how to do it a while back and ran into a brick 
wall.

> > 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. 

Well in the context of X, I suppose simplying the OpenGL connection is a 
good thing. DRI and all the rest of that bag of goods is overly 
complicated IMHO.

> 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 :-) 

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

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! ~