(blythe@bluevoid.com)Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies.
Permission to modify this document may be granted to those who get approval from David Blythe.
OpenGL is a registered trademark and SGI is a trademark of Silicon Graphics, Inc. Unix is a registered trademark of The Open Group. The `X' device and X Window System are trademarks of The Open Group. XFree86 is a trademark of The XFree86 Project. Linux is a registered trademark of Linus Torvalds. Intel is a registered trademark of Intel Corporation. 3Dlabs, GLINT, and Oxygen are either registered trademarks or trademarks of 3Dlabs Inc. Ltd. 3dfx, Voodoo3, Voodoo4, and Voodoo5 are registered trademarks of 3dfx Interactive, Incorporated. Matrox is a registered trademark of Matrox Electronic Systems Ltd. Rage is a registered trademark of ATI Technologies, Inc. All other trademarks mentioned are the property of their respective owners.
SGI maintains a sample implementation of GLX, OpenGL, and GLU., usually refered to as 'the SI'. This implementation serves as a reference implementation for SGI's OpenGL licensees. This implementation has been in development since 1992 and is the most mature implementation of OpenGL available. SGI made this sample implementation available as open source in January of 2000. The OpenGL implementation currently supports indirect rendering only. The GLX portion of the implementation has been integrated into XFree86 (4.0) by Precision Insight.
The SI consists of several pieces, the X server GLX protocol and OpenGL renderer implementation, the client side GLX and OpenGL bindings, the GLU implementation, header files, utility and sample code (sample code from the 'red book') and man pages.
More information on the SI implementation is available at http://oss.sgi.com/projects/ogl-sample/.
The Linux NVIDIA driver shares the same source code base with the Microsoft
Windows drivers so it has had a lot of application exposure and provides
the full OpenGL 1.2 features set as well as all of the NVIDIA extensions. The
driver consists of several parts, the 2D X driver, a loadable kernel
module that provides the direct rendering support, and the client
side code the application links to
(libGL.so, libGLU.so).
To allow the loadable kernel module to work with different versions
of the Linux kernel, NVIDIA ships some glue code in source form that
can be compiled against the kernel header files. This allows the module
to be used with minor variations in the kernel, e.g., 2.2.13, 2.2.14,
but a new release of the kernel module will likely be necessary for
major change in the kernel.
The GLU implementation is from the OpenGL sample implementation.
NVIDIA also provides an open source OpenGL and XFree86 3.3.5 driver implementation on their website. The implementation supports the NV1, RIVA 128, RIVA 128ZX, RIVA TNT, RIVA TNT2, and GeForce 256 chipsets. This driver has lower performance than NVIDIA's proprietary driver but it does include source code.
Although Accelerated-X is not Open Source, it is an OpenGL 1.1 implementation which supports accelerated textured polygons, fast clear, and fast swap, and provides acceleration for cards not likely to be supported through Mesa either because of lack of availability or lack of chipset documentation. Many 3D companies provide their chipset specification to Xi Graphics in order to receive OpenGL support on Linux such as Evans and Sutherland, SiS, and Number Nine.
Developers looking for a fully compliant OpenGL implementation and a vendor to provide support may contact Xi Graphics for more information.
Like the Xi Graphics product, this is a combination X server and OpenGL implementation. The implementation supports OpenGL 1.2 functionality with indirect rendering. There is not support for direct rendering, but any card supported by the X server can be used with OpenGL. The implementation is not available as open source.
HP is currently offering the Visualize series of X86-based workstations with NVIDIA TNT2 graphics ( http://www.hp.com/visualize/products/linux/ and has an fx-based product in Beta. The fx5 and fx10-based products use an X11 server derived from HP's HPUX code base, rather than XFree86 and includes a separate open source kernel module (leveraging code from the DRM/DRI) to provide direct rendering support. Longer term HP is looking at moving to a standardized infrastructure such as the DRI.
The behavior of the OpenGL API is defined by the OpenGL specification. A conformance test (called 'the conformance test') was developed by the OpenGL ARB for validating the correctness of OpenGL implementations. An implementation can only be called an OpenGL implementation and use the OpenGL logo if it passes the 'must pass' portion of the conformance test (and the implementation provider has a license from SGI). The 'must pass' part of the conformance test is not especially strict nor comprehensive, but provides basic testing that the OpenGL implementation works. There are additional tests in the conformance suite that licensed vendors must run, but they do not necessarily need to pass them to ship their implementation and still call it OpenGL.
Microsoft (yes, this has nothing to do with Linux), includes the 'must pass' test and several other tests in their Windows Hardware Quality Lab (WHQL) conformance suite, that vendors shipping on the Windows platform need to pass in order to receive WHQL certification.
Vendors may have their own internal test suites. SGI's ogtst was distributed to some of the SGI's licensees and its coverage has been increased over time. Allen Akin started glean, which is a an open source suite of tools for testing the quality of OpenGL implementations. glean can also be used to compare two OpenGL implementations and highlight the differences. More information on glean is available at http://glean.sourceforge.net/
Both the OpenGL sample implementation (SI) and Mesa have been tested using the OpenGL conformance test, and both pass most of the tests.
/usr/lib/libGL.so and Vendor B creates one called
/usr/lib/libOpenGL.so applications linked using Vendor A's
libraries will fail on platforms that have only Vendor B's libraries installed.
Similarly, to be able to compile an OpenGL application on different Linux releases without messing with lots of compile time configuration information, the locations of include files and contents of these files must be agreed upon. Some of the rules come directly from the OpenGL specification (e.g, the names of functions, #defines, etc), but others such as the location of include files, dynamic libraries, etc require a separate effort to achieve agreement.
Before looking at the Linux/OpenGL Base standard, it is useful to understand the versioning theory behind OpenGL. The OpenGL specification was written with the intent of having new functionality added over time. The rules for adding new functionality are simple, new functionality can not break compatibility with existing functionality. Therefore, tokens and symbols are never removed from the specification, and the definition of new functionality can not change old functionality in such a way that existing applications would break. For example, it is legal to add a new texture environment mode to combine a texture color and fragment color together, but it would not be legal to redefine the behavior of an existing texture mode.
The rules are simple, and they make it simple to release new versions of the library without breaking existing applications. If the OpenGL vendor follows the rules correctly (and doesn't introduce any bugs into their new implementation) then there is no reason to have anything other than the latest version of the library installed and there is no need to use any DSO versioning mechanism since the new library is backward compatible with old libraries.
For OpenGL SDK users the OpenGL header files all include tokens that define the version of OpenGL available on the system. These tokens can be tested at compile time to and allow developers to write portable application code that at compile time can optionally use new functionality when it is available. OpenGL also provides some mechanisms for testing for functionality at runtime, these mechanisms will be discussed later.
Problems with applications requiring a particular version of the library, for example, an application needing OpenGL 1.2 functionality, is left largely unaddressed by the OpenGL specification. Package installation tools such as the Redhat Package Manager are capable of testing for pre-requisites before installing an application. OpenGL provides a mechanism for querying the version at runtime, but the application is like to fail with unresolved symbols before the query is executed.
Besides additions to the core functionality, new functionality can be added in the form of extensions. In fact, it is preferred to vet new functionality first as an optional extension before adding it as baseline functionality. Extension management is a complicated topic and will be addressed after looking at standardization.
oglbase's scope is limited to just the OpenGL-related components (OpenGL, GLX, and GLU) on Linux under X11. Other Linux ABI and runtime standards are addressed by the Linux Standard Base (http://www.linuxbase.com/). Other OpenGL-related toolkits are left to their maintainers to decide on ABI issues.
A brief summary of Version 1.0 of the ABI is:
/usr/lib/libGL.so (DT_SONAME = libGL.so.1)
/usr/lib/libGLU.so (DT_SONAME = libGLU.so.1)/usr/include/GL:
<GL/gl.h> OpenGL 1.2 + ARB_multitexture defintions<GL/glx.h> GLX 1.3 + ARB_get_proc_address definitions<GL/glu.h> GLU 1.3 definitions<GL/glext.h> OpenGL extension definitions<GL/glxext.h> GLX extension definitionsgl.h defines GL_OGLBASE_VERSION-lpthread)Since version 1.0 has only recently become available, most providers of OpenGL implementations have not had enough time to produce compliant releases and older releases of OpenGL and OpenGL-like libraries are likely to be non-conformant. XFree86 4.01 includes oglbase conformant OpenGL support. Unfortunately, there will be period of turmoil as end users update their platforms to include oglbase compliant releases.
More information on the OpenGL Application Binary Interface for Linux is available at http://oss.sgi.com/projects/ogl-sample/ABI/
In order to use optional extensions at runtime the application developer includes multiple code paths in their application, a path that uses an extension and another that does not. When the platform does not include support for one of the extensions, the code path that does not use the extension is used instead. A problem remains in that the code that does use the extension, even though it is not executed, will result in references to unresolved symbols. There are several solutions to this problem. The first is to package the code path using the extension in a separate dynamic library (DSO) and only load it when the application will use that path. This can be rather cumbersome for the application developer. Another method is to allow applications to run with unresolved symbols. This works fine if the application never tries to execute code that uses those symbols, but it requires system support. The third option is to provide support in the library to bind symbols indirectly using runtime query functions to determine the addresses of the symbols rather than hard-coded references.
This third option has been included in the
OpenGL Application Binary Interface for Linux
as a GLX extension. The ARB_get_proc_address extension includes a new
GLX query that looks up the address of the named function, similar to
the dlsym() function for looking up symbols in dynamic
libaries.
Now an application that can take advantage of a particular extension
just needs to query for the presence of the extension using the
glGetString function and if the extension is present
query for the corresponding function address using
glXGetProcAddressARB. This provides an effective solution
for deploying portable OpenGL Linux application binaries that are
capable of using optionally using extensions.
Application developers may also be interested in making their source
code portable as well. There are two aspects in making the use
of extensions more portable in source code. The first is the specification
of the extensions. SGI maintains a registry of OpenGL extensions
(
http://oss.sgi.com/projects/ogl-sample/registry/)
that include a description of the behavior of the extension as well
as the the definitions of the symbols and tokens. This enables vendors
to work from a common definition of the extensions. The more significant
extensions may be elevated to ARB status making them more likely to
be implemented by multiple vendors.
The second component is that SGI maintains header files
(glext.h, glxext.h) that contain the
function prototypes and token values for the extensions available in
the registry. OpenGL vendors can include these files as part of
their distribution and if necessary application developers can download
(
http://oss.sgi.com/projects/ogl-sample/ABI/glext.h)
new versions of these files as extensions are added.
These header files are included as part of the oglbase standard and
are included automatically in gl.h and glx.h
unless
GL_GLEXT_LEGACY and GLX_GLXEXT_LEGACY are
defined at compile time.
A longer term goal for the DRI is to allow other OpenGL implementations to plug into the infrastructure and eliminate any need to have mutually incompatible versions of the OpenGL components on the same platforms. This would allow vendors to ship proprietary driver implementations and allow them to co-exist with open source implementations on the same platform. This will be benificial in the future for supporting multiple graphics cards simultaneously.
The OpenGL sample implementation has only recently been made available as open source. The implementation has been integrated with XFree86 3.3.6 and is in the process of being upgraded to XFree86 4.0.
SGI plans to make some additional software available as open source. Some parts under development include optimized geometry code for the SI implementation, the OpenGL Stream Codec (GLS), and the OpenGL Character Renderer (GLC).
There are some small issues with the current specification that still need refinement or clarification. These include ensuring that dependencies on other libraries are either eliminated or full defined, e.g. in terms of the Linux Base ABI.
Finally, as new extensions become available and OpenGL evolves, these need to be considered for inclusion in future versions of the ABI.
OpenAL provides 3D spatialized sound; it has the concept of a spatial listener and multiple sound sources; each has a velocity, orientation, and position. The following code sets up a listener and a simple source and plays a sample for a short period of time.
ALuint buf;
ALsizei size, bits, freq, format;
ALfloat back[] = {0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 1.0f};
alutinit(&argc, argv);
alGenBuffers( 1, &buf_id );
alutLoadWAV( "sound.wav", &wave, &format, &size, &bits, &freq);
alBufferData( buf_id, format, wave, size, freq );
free(wave); /* openal makes a local copy of wave data */
alGenSources( 1, &source_id);
alSource3f(source_id, AL_POSITION, 0.0, 0.0, -5.0);
alSourcefv(source_id, AL_ORIENTATION, backwards);
alSourcei (source_id, AL_BUFFER, buf_id);
alSourcePlay(source_id);
sleep(10);
alutExit();
OpenAL is available from the OpenAL
web page at www.openal.org
OpenML is being modeled on the successful dmSDK digital media libraries on IRIX from SGI. Initial implementations of OpenML will contain software emulation of many features, with the intent (like OpenGL), that individual vendors will optimize paths through OpenML that correspond to their market segment and their hardware feature set. We don't anticipate seeing mature OpenML implementations within the next year.
By the end of the year, we expect that drivers for the DRI and SI should bring robust production-quality OpenGL for Linux to the most popular commodity and high-end boards available.