NVIDIA has released yesterday a new set of graphics drivers for Linux, FreeBSD and Solaris. The main new change brought by this driver is the support of GLVND or OpenGL Vendor Neutral Dispatch Library.
You can download R361.16 from THIS PAGE.
Here is a detailed explanation about libglvnd, from Mesa-dev:
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.
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.
R361.16 exposes the same OpenGL extensions than R358.16.