Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 18+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium.
Yes, Mesa Is Working Towards GLVND Support
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.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."
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.
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.