Re: DRI integration

Around 21 o'clock on Nov 12, Keith Whitwell wrote:

> In general this isn't a problem.  Exporting bits of hardware functionality not 
> covered by GL is typically a doddle.  It'd be interesting to know what you're 
> referring to.  It may even just be a case of digging out some little used 
> aspect of GL & properly optimizing the implementation.

I was thinking a bit more about this and I'm wondering if we can manage to
give the X server direct access to the frame buffer and ancilary off-screen
images.  This would allow X to use GL as strictly an acceleration mechanism
instead of the sole method for drawing to the screen.

I realize this breaks nearly every abstraction designed into GL, but it
would *dramatically* reduce the time it takes to get a complete, working X
implementation running, and let us focus on what GL can do to accelerate X,
rather than implement all of the weird X semantics.

I've developed X servers for abstract rendering interfaces in the past and
I know what a huge effort it can be to cover every single case, especially
when the underlying system has some semantic mis-match with the X rendering
primitives.  Providing a slow-but-direct method means we can move 
incrementally towards improved acceleration, rather than having to jump 
all at once.

Of course, when we do identify key functions not available in GL but 
required for good X performance, we would want to implement those as GL 
extensions (who knows, GL applications may even find them useful :-).

From my own perspective, I can say that working on a functioning if slow
system is far more fun than working for weeks on a system which does not
work at all.  And, I don't relish the thought of spending those weeks 
implementing code which I expect to never be executed by modern 
applications and only infrequently used by even the most ancient.

-keith