A New Linux OpenGL ABI Is Being Proposed

The Linux OpenGL stack along with the upstream OpenGL specification has been evolving at a fast pace in recent years. There was recently some discussion within the Khronos camp for updating the guide for how to implement OpenGL support on Linux and it's been decided it will be talked about next week at XDC2012. To get the ball rolling for planning out a new Linux OpenGL ABI, NVIDIA has published a proposal.

Andy Ritger of NVIDIA has sent out a straw-man proposal for a revised Linux OpenGL ABI in advance of next week's meeting in Nürnberg. The current Linux OpenGL ABI is effectively twelve years old now and is in need of being updated. Among the reasons that an update is needed comes down to:

- EGL showing it can be a compelling alternative to GLX for the windowing system binding. Intel has already told application developers to target EGL rather than GLX. Wayland also does away with GLX in favor of EGL. An Intel Linux developer has also been working on Waffle for run-time selection of the windowing system and GL implementation.

- The OpenGL API has advanced greatly over the past decade.

- Deciding what to do about GL_ARB_compatibility entry points.

- It's a major pain for both Linux software vendors and end-users that the current ABI doesn't allow multiple vendors' OpenGL implementations on the same file-system. A.k.a. each driver shipping its own libGL.so.1 that causes clashes with other drivers and lead to headaches when installing/removing graphics drivers. Solving this will perhaps be the most noticeable change for end-users.

As written within Andy's initial straw-man proposal, the new Linux OpenGL ABI won't seek to push this standard to Android or other embedded Linux implementations. It's also not being forced onto other UNIX-like systems such as BSD or Solaris, but in the end it may carry relevance there too.

For not breaking compatibility with existing OpenGL/GLX programs of the past decade, the existing application ABI should be preserved although likely to be deprecated. Again, the most positive point illustrated for end-users is that multiple OpenGL vendor driver implementations must be able to co-exist on the same file-system without colliding -- this will be really great to see!

The existing libGL.so.1 library should end up being a vendor-neutral API library that plugs into a libOpenGL.so.1 and libGLX.so.1 for fitting into this new ABI equation and not regressing on existing Linux OpenGL support. The proposed libOpenGL.so.1 library would then be this new interface that provides symbols for a to-be-determined version of OpenGL, no EGL/GLX entry points will be provided (like GLX with libGL), and functions for vendor OpenGL libraries to provide their dispatch table and reporting their GetProcessAddress-able functions. There would also be new EGL and OpenGL ES libraries.

The vendor/driver-specific libraries would likely carry a postfix of the vendor's name, e.g. libEGL_nvidia.so.1, so that there wouldn't be library collisions like there is now and these driver libraries then would register with the generic API library that interfaces with the user-space application.

There's certainly a need for an updated Linux OpenGL ABI and it's likely to happen. The specific details mentioned in this article are just the initial ideas expressed by Andy Ritger of NVIDIA's UNIX/Linux team to get the ball rolling. More specifics will be discussed next week from XDC2012, which will be covered on Phoronix. This new Linux OpenGL ABI though won't materialize over night and will likely be a while before it's adopted across the board for the benefit of the Linux desktop.

The initial proposal in full can be found on the mesa-dev mailing list.