Google Summer of Code 2008 query
If I understand correctly, the current plan is maybe to write a "DRI driver using OpenGL.framework", but have enough decisions been made to even formulate some sort of proposal for Google Summer of Code 2008? Sorry for the relatively late inquiry.
If you search the xquartz-dev and x11-users archives, you should find some discussion about this. Pelle Johansson and I both made some stabs at fixing DRI for OSX. Pelle made a bit more progress than I did (there are patches in this lists archives around March 7)... but this still used Apple-DRI. We'd like to migrate over to using XF86- DRI instead, so we don't waste cycles re-creating the wheel. Plus this allows us to just maintain the interface between Mesa and OpenGL.framework rather than the entire DRI infrastructure as well. --Jeremy On Mar 26, 2008, at 21:30, David Shao wrote:
If I understand correctly, the current plan is maybe to write a "DRI driver using OpenGL.framework", but have enough decisions been made to even formulate some sort of proposal for Google Summer of Code 2008? Sorry for the relatively late inquiry. _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
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. 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. 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. -- Pelle Johansson 28 mar 2008 kl. 03.36 skrev Jeremy Huddleston:
If you search the xquartz-dev and x11-users archives, you should find some discussion about this. Pelle Johansson and I both made some stabs at fixing DRI for OSX. Pelle made a bit more progress than I did (there are patches in this lists archives around March 7)... but this still used Apple-DRI. We'd like to migrate over to using XF86-DRI instead, so we don't waste cycles re-creating the wheel. Plus this allows us to just maintain the interface between Mesa and OpenGL.framework rather than the entire DRI infrastructure as well.
--Jeremy
On Mar 26, 2008, at 21:30, David Shao wrote:
If I understand correctly, the current plan is maybe to write a "DRI driver using OpenGL.framework", but have enough decisions been made to even formulate some sort of proposal for Google Summer of Code 2008? Sorry for the relatively late inquiry. _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
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
28 mar 2008 kl. 18.50 skrev 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.
Sounds good. I just took a look at the mesa commit log, and it seems like Kristian Høgsberg <krh@redhat.com> is working on a version 2 of the XF86Dri protocol, and is abstracting out the calls to work with version 1 or 2. Looks like the perfect opportunity to do this part as well (so far it still seems to depend on libdrm). Looks like his changes could've helped applying Apple-DRI the old way more clean as well... -- Pelle Johansson
participants (4)
-
David Shao
-
Jeremy Huddleston
-
Jeremy Huddleston
-
Pelle Johansson