Mesa (computer Graphics) - History

History

Project initiator Brian Paul was a graphics hobbyist. He thought it would be fun to implement a simple 3D graphics library using the OpenGL API, which he might then use instead of VOGL. Beginning in 1993, he spent eighteen months of part-time development before he released the software on the Internet. The software was well received, and people began contributing to its development. Mesa 3D started off by rendering all 3D computer graphics on the CPU. Despite this, the internal architecture of Mesa 3D was designed to be open for attaching to graphics processor-accelerated 3D rendering. In this first phase, rendering was done indirectly in the X server, leaving some overhead and noticeable speed lagging behind the theoretical maximum.

The first true graphics hardware support was added to Mesa in 1997, based upon the Glide API for the once new 3dfx Voodoo I/II graphics cards and their successors. A major problem of using Glide as the acceleration layer was the habit of Glide to run full screen, which was only suitable for computer games. Further, Glide took the lock of the screen memory, and thus the X server was blocked from doing any other GUI tasks.

At the time 3D graphics cards became more mainstream for PCs, individuals partly supported by some companies began working on adding more support for hardware-accelerated 3D rendering to Mesa 3D. The Direct Rendering Infrastructure (DRI) was one of these approaches to interface Mesa, OpenGL and other 3D rendering API libraries with the device drivers and hardware. After reaching a basic level of usability, DRI support was officially added to Mesa 3D. This significantly broadened the available range of hardware support achievable when using the Mesa library.

With adapting to DRI, the Mesa library finally took over the role of the front end component of a full scale OpenGL framework with varying backend components that could offer different degrees of 3D hardware support while not dropping the full software rendering capability. The total system used many different software components.

Even if those design needs all components to correctly cooperate with each others, the interfaces between them are relatively fixed but still see coordinated improvements even today. As a result, the software development on the individual modules can still be kept separated. As most of the code is open source, it still happens that, for experimental works on new features and enhancements, programmers sometimes create their own branch of altered modules until their results might show their conceptual success and can be merged back in a more or less compatible fashion to the main trees of all altered components and then typically ending up as a part of the next major or minor release. That applies e.g. to the update of the DRI specification in form of DRI2 as developed and published with a first reference implementation in years 2007 to 2008 that, for example, comes with no locks any more and improved back buffer support. For this, a special git branch of Mesa was created.