<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    A bit of background: Libglvnd was originally proposed back at XDC
    2013. It's hosted on Github here:<br>
    <a class="moz-txt-link-freetext" href="https://github.com/NVIDIA/libglvnd">https://github.com/NVIDIA/libglvnd</a><br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    The EGL interface is still in its really early design stages. Any
    comments or requirements that I might have forgotten are more than
    welcome.<br>
    <br>
    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:<br>
    <a class="moz-txt-link-freetext" href="https://github.com/kbrenneman/mesa-libglvnd">https://github.com/kbrenneman/mesa-libglvnd</a><br>
    <br>
    Internally, it's broken down into a few different libraries:<br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Comments, questions, and suggestions are all welcome.<br>
    <br>
    Thanks,<br>
    -Kyle Brenneman<br>
    <br>
  </body>
</html>