Re: DRI integration

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

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

Yes, we could use read/draw pixel primitives, but that would entail 
rewriting all of the rendering code.  I'm interested in an architecture 
that will let us slowly move to GL acceleration while having a working X 
server the whole time.  Touching the pixels directly is clearly the 
shortest path from my perspective; I'm interested to know if it is easily 
done in GL, even if it does completely wreck the device abstractions.  

We may want to implement on top of read/draw pixels at some point so we 
can have a pure GL X server; useful were the hardware vendor doesn't 
provide anything other than the GL API, but performance will suffer.

For now, we're not talking only about archaic usage; GL cannot render any 
of the text on my screen.  Using read/draw pixels is a huge performance 
problem because reading pixels is so slow, and I really only need to read 
a small fraction of the area covered by each glyph as most of the written 
pixels are either transparent or 
opaque.

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

Yes, I think we would insist that GL be the only way of getting at the
hardware acceleration; the alternatives are just too complicated to
consider (saving/restoring state, etc).  We've already done that with DRI/X
integration today and I think I could find many people interested in
avoiding a reprise.

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

Certainly implementing existing useful standards would be better than 
developing custom kludges; when we start looking at accelerating 
unsupported operations, we'll want to read through the specs carefully and 
borrow where appropriate.

-keith