[Mesa-dev] [RFC] Vendor-neutral dispatch library for OpenGL

[Kyle Brenneman]

On 10/06/2015 07:34 AM, Emil Velikov wrote:
> Hello Kyle,
>
> A few questions/points of discussion:
>
>   * What is your take on having a libglvnd 'package', which provides
> the headers (and maybe other materials), apart from the libraries ?
> I'm basically thinking about OpenGL.h, GLX.h, etc for programs that
> wish to use new ABI, and glvnd{Foo,Bar}.h which mesa and other GL
> implementations.
I haven't looked much into packaging yet. I'm open to any suggestions 
that might make that easier, though.

One thing that I'm planning to do but haven't gotten to yet is to move 
the public headers into a separate directory. There's a couple of header 
files (libglxabi.h and GLdispatchABI.h) that are intended to be used by 
vendor library implementations, and the other headers are all internal.

The headers that you'd use for compiling an application (gl.h, glx.h, 
etc.) could easily go into a separate package, too.

>   * (Slightly out of scope here) Has there been any plans to have an
> interop between vendors' GL implementations ? I am leaning towards
> 'nearly impossible' and 'with limited to no interest from the
> different vendors'.
It hasn't come up yet. Most of the design focuses on keeping the 
different vendor libraries separate from one another.

My first inclination would be that any form of interop between vendor 
libraries would be outside the scope of libglvnd itself. Without a 
specific case for how that should work (for example, how a vendor 
library finds and decides which other vendor library to talk to), it's 
better left as a separate interface.

>
>   * There was an idea to expose separate libOpenGL libraries, one for
> each (major?) GL version.
> What happened on that front ?
Nothing as far as I know.

However, each of those libraries is basically just a thin wrapper around 
libGLdispatch.so, so in theory you could define any number of libraries 
that just export a different set of functions. It's more a question of 
how many libraries we'd want to deal with.

 From an application standpoint, having a fixed set of libraries with a 
known set of exported functions seems like the easiest option, since you 
could then link your application against it and not have to modify it later.

That said, the set of functions to export from libGL.so and libOpenGL.so 
is still an open question. The set right now is just what libglvnd 
inherited from Mesa, but it would be good to have a more clearly-defined 
set. Maybe something simple like all core OpenGL functions through 
version 4.5 or so?

>
>   * The existing x11glvnd extension seems to be a "xserver only" approach.
> Iirc at XDC last year, people were leaning towards using an FD to
> obtain all the information needed. Currently mesa/xserver uses that to
> detect if we should load i915, i965, r300, r600... driver. What's your
> take on this ?
I'm open to alternatives, but I'm not familiar with the FD approach 
you're describing. Can you give me more details about it, or point me at 
where in the Mesa code it is?

>
>   * The POC code at github looks quite good and consistent.
> Here are a few bits, in case you're interested.
> - We're building either libGLX_mesa or libGL, but never both.
> - Lovely interactions with --with-gl-lib-name. Perhaps we should
> remove the latter.
> - Insanely long lines and other coding style nitpicks.
> - 'Export what you need'
>
>
> Cheers,
> Emil