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.

In general it does, and there is hardware like you mention where it will be 
impossible.  However, all the current DRI supported hardware at least has an 
existing 2D DDX which has direct access to the framebuffer.

While GL doesn't permit regular applications direct access to the frontbuffer 
(there are extensions to get access to chunks of offscreen or AGP memory), the 
X server is enough of a special case that an exception can be made.

It would certainly be cleaner to have everything go through GL, though.

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

As the nature of 2d rendering changes and potentially looks more like 
traditional 3d rendering - lots of geometry, texture or other high-bandwidth 
needs, forinstance, the old results may no longer apply.

> 
> Besides, the X server will still be needed for remote application 
> rendering, just as it does with GLX today.

Yep.

Keith