Re: DRI integration

Keith Packard wrote:
> Around 14 o'clock on Nov 13, Brian Paul wrote:
> 
> 
>>I don't see that as an abuse of GL.  It seems reasonable to allow 
>>image buffers to be accessed by any number of renderers.
> 
> 
> Ok, cool.  I thought GL was generally designed to completely hide the 
> frame buffer from the application; certainly the original SGI hardware 
> didn't let the CPU touch it directly.

Perhaps I wasn't clear enough.  In general, you probably don't want to 
give client programs direct access to the frame buffer (indeed it 
could be impossible w/ some hardware).  I'm saying that OpenGL, the X 
server, Render and other renderers could all have direct access to the 
frame buffer and misc image buffers.

That said, there's nothing to prevent the development of a GLX 
extension that might expose the framebuffer or off-screen image 
buffers to clients via mmap'ing or some other technique.  Again, this 
may not be feasible on some hardware.


>>So which aspects (specifically rendering operations) of "Xlib-on-GL" 
>>concern you, if wide lines, plane masks, etc aren't a big deal?
> 
> 
> I do need an X server for complete X semantics, including window management
> and interclient communication.  As such, redirecting rendering from
> applications through the X server and thence to GL provides a very
> straightforward development path.  We've tried direct rendering with 2D in
> the past many times and haven't found it useful, but perhaps we will want
> to try again once X itself is better integrated into a direct rendering
> framework.
> 
> Besides, the X server will still be needed for remote application 
> rendering, just as it does with GLX today.

I should have said "X server on GL", not "Xlib on GL".

I'm still wondering which primitive X operations (like blitting or 
text rendering, etc) might be difficult to map onto GL in your opinion.

-Brian