[RFC] GLX dispatch rewrite

[Jeremy Huddleston Sequoia]

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 <jeremyhu at freedesktop.org> 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 <ajax at redhat.com>
> 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 <ajax at nwnk.net> 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
>> 
>> _______________________________________________
>> xorg-devel at lists.x.org: X.Org development
>> Archives: http://lists.x.org/archives/xorg-devel
>> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>> 
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4154 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131126/a48ae477/attachment-0001.bin>