Re: Why run xserver on the OpenGL API?

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

Good points.

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

Well I was more thinking along the lines of at least enabling a path for 
a 2D only driver to work within the 3D driver framework. So OpenGL will 
still be a part of the complete picture, just maybe slow because it would 
be in software.

Then again this is something I am already working on (hooking 2D 
functions inside the OpenGL software rendering pipeline with SNAP), so 
maybe I can provide that part of the system.

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

Right, but my point is you still need a 2D engine to do this. I don't 
think there is any way to do a 2D style BitBlt using the 3D engine. So at 
the BitBlt engine at least will need to remain in order to support window 
scrolling with any kind of decent speed even in next gen hardware.

But that is getting a bit off topic ;-)

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

Yep. I am slowly coming around to this camp, and perhaps the work we are 
doing right now will help answer some of those questions to determine 
it's feasibility. 

We are hoping that soon we will have hardware 3D drivers ported from DRI 
code working within the SNAP driver architecture using Mesa. This would 
all be completely outside of X so it could be used as the basic 
underlying foundation for an X server very easily (especially since we 
already have a SNAP X server module). The primary difference is once you 
have the driver loaded, you just request the OpenGL entry points and 
voila, the complete OpenGL API is at your disposal with a nice, clean 
buffer manager API to manage all the surfaces without glX etc.

Right now all this is working great with software only (and some basic 2D 
functions used for screen clears etc), and we are working on the plug in 
driver module system. Most of this work got held up a month or so back 
when we ran into problems with the C runtime library we are using for our 
driver modules. Some arcane bugs (still unknown) in the math library 
would cause Mesa to do weird stuff when built as a SNAP module. That 
combined with the lack of C++ support (to build the GLU code into a SNAP 
module for embedded apps) forces us to speed up the port of the Open 
Watcom runtime library for use in SNAP drivers. I completed that work 
last week, and now Mesa works perfectly and we can properly build and 
load the SGI GLU code as well.

So hopefully soon I can get back to porting the Radeon DRI driver code. 
Of course I also have to get the Parhelia driver done for IBM as well as 
wrap up the SNAP DDK (now that we have the runtime libs done ;-)...

I guess a good step would be to start working on getting xserver to work 
with SNAP drivers, at least for the 2D case? If that is done, since we 
already export software OpenGL that should provide enough to allow 
someone to test out the theory of using OpenGL functionality for a back 
end X server DDI...

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