Yes, Mesa Is Working Towards GLVND Support

Written by Michael Larabel in Mesa on 17 January 2016 at 08:20 AM EST. 10 Comments
MESA
With yesterday's news about AMD planning GLVND support for their Linux driver -- which follows the NVIDIA 361 driver being the first to ship GLVND, years after NVIDIA began working on this OpenGL Vendor-Neutral Dispatch Library -- many have been wondering how Mesa fits into the equation.

Mesa must too receive GLVND support for this to all work out. If Mesa doesn't support GLVND, on a new install/upgrade it could end up clobbering GLVND's vendor-neutral libGL wrapper to libGLX/libGLdispatch and things wouldn't work for reaching GLVND's design of making it easier to install and maintain Linux OpenGL drivers.

As has been cited since yesterday's post about AMD GLVND, back in September is when NVIDIA posted an experimental libglvnd Mesa patch. That post does a nice job as well at covering the GLVND basics if you're still unsure about it:
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.
The Mesa developers do have interest in libglvnd contrary to not a lot of mailing list discussion on the matter. Timothy Arceri of Collabora commented on yesterday's article that work in fact is being done, "Emil from Collabora is working on the Mesa support on behalf of Intel. He also has provided feedback along the way."

Hopefully 2016 is the year of the new OpenGL Linux ABI! Since let's face it, OpenGL is still going to be around for years to come even after the premiere of Vulkan.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week