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

Kyle Brenneman kbrenneman at nvidia.com
Wed Sep 30 13:07:52 PDT 2015


I'm working on libglvnd, a vendor-neutral dispatch library for OpenGL, 
and I wanted to see if anyone had any comments or suggestions about it. 
Right now, I'm trying to get the GLX interface wrapped up, but I'd like 
to get some feedback from the Mesa community before I'd be confidant in 
calling it ready.

A bit of background: Libglvnd was originally proposed back at XDC 2013. 
It's hosted on Github here:
https://github.com/NVIDIA/libglvnd

The goal for libglvnd is to allow multiple OpenGL implementations from 
different vendors to coexist on the same system, without interfering 
with each other or requiring any manual configuration.

With libglvnd, libGL.so is a vendor-independent dispatch library, not 
part of any driver. Each vendor provides its OpenGL implementation in a 
separate library. An application still links to libGL.so just like it 
does now, but then libGL.so will figure out which vendor library to use, 
and will dispatch any OpenGL and GLX calls to that library.

The libglvnd libraries make as few assumptions as possible about how the 
vendor libraries work, so that (hopefully) it's easy to port any 
existing OpenGL implementation to it. In some cases, a simple wrapper 
library around an existing libGL.so library would be enough.

As it's currently implemented, libglvnd selects a vendor library for 
each X screen. So, you could have two X screens that each use a 
different vendor library, and a single process could create and use 
rendering contexts on both. It doesn't handle two different vendor 
libraries for the same X screen, although the ABI is set up such that it 
would be possible to add that capability later on.

The EGL interface is still in its really early design stages. Any 
comments or requirements that I might have forgotten are more than welcome.

In addition, I've put together a proof-of-concept version of Mesa that 
can use libglvnd. It's still a work in progress, but hopefully it will 
provide a more concrete example of how libglvnd works. I've got it 
checked into Github here:
https://github.com/kbrenneman/mesa-libglvnd

Internally, it's broken down into a few different libraries:
libGLX handles GLX functions, and is responsible for keeping track of 
GLX contexts, selecting and loading vendor libraries, and setting up the 
dispatch table for OpenGL functions. This is the only library that a 
vendor library directly talks to.

libGLdispatch is responsible for dispatching OpenGL calls to the correct 
library based on the thread's current rendering context. It uses a 
dispatch table derived from Mesa's GLAPI layer. libGLdispatch is purely 
internal -- the vendor libraries go through libGLX to set up dispatch 
tables, and an application would call into libGL.so or libOpenGL.so to 
call any OpenGL functions.

libGL.so is a wrapper around libGLX and libGLdispatch. Conceptually, it 
just exports GL and GLX functions and forwards them to libGLX and 
libGLdispatch to deal with. The implementation is a bit more complicated 
to avoid the overhead of an extra indirect jump every time an app calls 
an OpenGL function.

In addition, there's a new library, libOpenGL.so. It's basically the 
same as libGL.so, except that it only exports the OpenGL functions, not 
GLX. It also doesn't depend on libGLX, so it could also be used with an 
EGL or GLX application. The hope is that future applications will link 
against libOpenGL.so and either libGLX.so or libEGL.so. This makes for a 
cleaner separation of OpenGL from the window system binding. But, 
libGL.so will be kept around indefinitely for backwards compatibility.

Comments, questions, and suggestions are all welcome.

Thanks,
-Kyle Brenneman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150930/b21bc24c/attachment-0001.html>


More information about the mesa-dev mailing list