DRI (Was Re: [Xquartz-dev] Google Summer of Code 2008 query)

[Jeremy Huddleston]

On Mar 28, 2008, at 00:38, Pelle Johansson wrote:
> Well, as for planning how it should be done, once an understanding  
> is grasped of the source tree, I think it should go something like  
> this.
>
> 1) Separate out the tight dependency of the drm library from the  
> XF86Dri protocol, from xserver and mesa.
>
> That would be the optimal solution, but requires cooperation with  
> the linux/bsd X developers. It they object to this, the alternative  
> is to make a fake drm library for OS X, even though the architecture  
> is completely different.

I'm pretty sure there should be little to no resistance here from the  
community.  I think the tight dependency on drm was just because it  
was quicker than putting in the abstraction and they didn't see anyone  
needing it at the time.  Still, if you look at Pelle's patch, you'll  
see the integration hasn't turned into spaghetti quite yet.

> 2) Implement the server side dri driver.
>
> If I'm correct (Jeremy might fill in here), OS X does not need much  
> server side support for DRI. This would be a file implementing the  
> same protocol as xserver/hw/xfree86/dri/dri.c, probably based on  
> xserver/hw/xquartz/xpr/dri.c.

Yep.  Pretty much.  In fact, xpr/dri.c was originally based on the  
original xfree86/dri/dri.c ... so it's highly probable that copying in  
the "new" xfree86 dri.c and cherry-picking code out of our existing  
xpr dri.c might be all that's involved here.  Note that we also will  
no longer need to build xserver/GL/apple

> 3) Do the client side driver.
>
> Here I'm getting less knowledgeable at the specifics, someone else  
> might que in. But it should be implementing the mesa driver  
> interface, and call the functions in OpenGL.framework.

The DRI driver itself should be the interface itself that both Xquartz  
and libGL.dylib use to ask the hardware to do some OpenGL rendering.

When we use AIGLX (X server side OpenGL rendering), libGL packs up the  
GL command is packed up in an X protocol request, sent to the server,  
unpacked, and the X server then uses the DRI driver to ask hardware  
(OpenGL.framework) to render into a particular context.

When we use client-side DRI, libGL uses the DRI driver to ask hardware  
(OpenGL.framework) to render into a particular context.

When server == client, client-side DRI is faster.  When client ==  
lightweight and server == massive 3D hardware, the X protocol overhead  
becomes minimal compared to the increased rendering speed and it  
becomes advantageous to do AIGLX over local rendering.

But in both cases (using Xquartz as the server and using a Mac OSX  
client), our DRI driver should be the same, so we don't need to manage  
two separate dispatch tables as we are now.

--Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3221 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080328/6e2bd6fd/smime-0001.bin