[RFC] GLX dispatch rewrite
Adam Jackson
ajax at nwnk.net
Mon Dec 2 09:09:44 PST 2013
On Fri, 2013-11-29 at 15:20 -0800, Jeremy Huddleston Sequoia wrote:
> On Nov 29, 2013, at 12:13, Keith Packard <keithp at keithp.com> wrote:
> > Jeremy Huddleston Sequoia <jeremyhu at freedesktop.org> writes:
> >
> >> 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).
> >
> > I'd love to understand this issue a bit better, and am willing to hold
> > the non-critical bug window open another few days to see if we can't
> > come up with a solution before we abandon GLX support on non-DRI
> > platforms.
> >
> > As I understand things, Adam's plan was to eliminate going through the
> > DRI driver's dispatch table and instead bind directly to libGL
> > itself. As such, that doesn't seem to directly bear on systems that
> > don't go through the DRI loader interface.
> >
> > I'm sure someone can explain the reason these systems are unable to link
> > to libGL and use the symbols directly, so I'd like to know what we need
> > to put back into the X server to make them work.
>
> The problem is not with the elimitaion of the DRI loader interface but
> with the elimination of glapi dispatch that happened at the same time.
>
> We can't guarantee what symbols (ie OpenGL extensions) will be
> available in libGL at link time and runtime which is why I wrote
> _glapi_create_table_from_handle. This fills out the dispatch table
> with entry points into our libGL (or no-op entries if unavailable).
Right, but that lack-of-guarantee is true of Linux too. glxstubs.c is
incomplete evidence of this. I ought to just flesh that out the rest of
the way.
Practically speaking GLX requires OpenGL 1.2, which even OSX 10.0 had,
and which the Linux ABI does guarantee. So directly linking to those
symbols and glxstubs'ing the rest seems like the way forward. I'll try
to type that up today. If, in exchange, someone would review my most
recent series, that'd be very kind of them.
- ajax
More information about the xorg-devel
mailing list