Re: DRI integration

Keith Packard wrote:
> 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.

The current situation where the X server doesn't use GL works this way, so 
it's clearly not impossible.

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

And this sounds reasonable too.  I'm interested in understanding the wierd 
stuff, and knowing if it is important enough to break the abstraction for -- 
GL does supply read & draw pixel primitives which could be used to suck 
regions out of the framebuffer, modify them & redraw them.  If we're only 
talking about archaic usage, that might be sufficient.

It's also worth noting that historically (I'm told) there hasn't always been a 
memory-mappable framebuffer in 3d hardware.

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

I don't see a problem with this, given the intention to move closer & closer 
towards GL integration, perhaps by extending GL.  If ever the discussion moves 
towards doing hardware acceleration outside of GL, I start to get nervous...

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

Correct.

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

Understandable.

While you're thinking about this stuff, it's probably worthwhile looking at 
the vertex and fragment programmability stuff that has emerged over the last 
few years. (note that none of the DRI hardware really support this stuff, though).

Keith