Re: DRI integration

I've just joined this list...

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



Implementing X operations in terms of OpenGL is a common 
question/topic.  Some things are pretty straightforward, but others 
aren't.

Line drawing is one such problem.  Simple horizontal/vertical lines 
are easy enough, but touching the right pixels on diagonal lines, wide 
lines and line caps/joins are hard.  Doing that stuff with 
glDrawPixels or individual GL_POINTS would be rather inefficient.

X's plane masks are another.  OpenGL has plane mask for color index 
mode, but not RGB.  Though, I'm not sure how important this stuff is 
to X nowadays anyway.

If OpenGL replaced Xlib's drawing functions I'd like to think that a 
small OpenGL extension could be designed to make up the difference 
from Xlib's rendering feature set.

Has anyone ever exhaustively explored/documented how X's rendering 
operations might be mapped to OpenGL?  That could be an interesting 
project.

-Brian