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