So what's the story on this? How should we solve this for xquartz and xwin? Should we pull the old code into hw/xquartz/GL and hw/xwin/GL? That seems redundant. So should we restore it in some other way? I'd really like to get master working for OS X (at-least XQuartz, but hopefully Xorg as well).
--Jeremy On Nov 13, 2013, at 9:47, Jeremy Huddleston Sequoia <[email protected]> wrote: > Hey ajax, > > Here's another XQuartz build regression from the GLX rework. > > Your commit (referenced below) got rid of _glapi_create_table_from_handle > along with the rest of glapi.h. I specifically created > _glapi_create_table_from_handle for XQuartz (mesa: > 85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b, xserver: > ecec578e35f91a2cbc5d07bc8d45241af7bb585f > 34e2598f0ad247071bd6a4312d9014d6e3b2305a) so we could create our GL dispatch > table dynamically at runtime. > > How should XQuartz be dealing with GLX dispatch in this new world order? > > > commit be6680967a479eedbcab2fe1718c5f981e1029c7 > Author: Adam Jackson <[email protected]> > Date: Wed Jul 10 10:00:46 2013 -0400 > > glx: convert to direct GL dispatch (v2) > > We now expect to be linked against something that provides the GL API, > instead of manually grubbing about in the DRI driver's dispatch table. > Since the GLX we expose calls GL functions that are meant to be looked > up dynamically, also add a way to thunk through to GetProcAddress. > > > On Oct 28, 2013, at 13:29, Adam Jackson <[email protected]> wrote: > >> On Tue, 2013-10-22 at 14:27 -0400, Adam Jackson wrote: >>> I'd send this as a patch, but it's like 2M, so I figure that's rude. >>> Instead see here: >>> >>> http://cgit.freedesktop.org/~ajax/xserver/commit/?h=glx-direct-dispatch&id=918c1e76b1ee837db36283dc8fe513fc588c1e4d >>> >>> Basically this rips out the fork of glapi from xserver, and converts the >>> glx code to call into libGL directly. What it _doesn't_ include is >>> converting the loaders to EGL. I still plan to do that at some stage, >>> but it turns out they're separable tasks. I've verified that indirect >>> contexts with Xvfb pass exactly as many piglit tests [1] before and >>> after this patch (plus my previous memory-leak-fix series, since >>> otherwise Xvfb gets oomkilled). >> >> Delightfully, testing this against Xorg (ivybridge, glamor) not only >> passes more piglits (1274/1766) than it did before (899/1684), but 13 of >> those new passes are tests that previously crashed Xorg. >> >> - ajax >> >> _______________________________________________ >> [email protected]: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel >> > > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
