| <?php |
| $static_title = 'OpenGL® Application Binary Interface for Linux'; |
| $static_breadcrumb = array( |
| '/registry/' => 'Registry', |
| '/registry/OpenGL' => 'OpenGL', |
| 'NOLINK' => 'ABI' |
| ); |
| include_once("../../../assets/static_pages/khr_page_top.php"); |
| ?> |
| |
| |
| <h1 style="text-align:center"> |
| OpenGL® Application Binary Interface for Linux <br/> |
| <span style="font-size:12px"> (formerly Linux/OpenGL Base) </span> |
| </h1> |
| |
| <p style="text-align:center">Version 1.0<br/> |
| Approved June 20, 2000<br/> |
| Editor: Jon Leech, SGI </p> |
| |
| <hr/> |
| |
| <h6>Latest News</h6> |
| |
| <p> Version 1.0 is complete. It was approved on June 20, 2000; all |
| submitted votes were in favor. </p> |
| |
| <hr/> |
| |
| <h6>Index</h6> |
| |
| <ul> |
| <li><a href="#1">1. Overview and Goals </a></li> |
| <li><a href="#2">2. Calling Conventions</a></li> |
| <li><a href="#3">3. Libraries</a></li> |
| <li><a href="#4">4. Header Files</a></li> |
| <li><a href="#5">5. Extension Headers</a></li> |
| <li><a href="#6">6. Feedback and Mailing Lists</a></li> |
| <li><a href="#app">Appendix: Open Issues</a></li> |
| <li><a href="#log">Change Log</a></li> |
| </ul> |
| |
| <p> <a name="1"></a></p> |
| <h6>1. Overview and Goals </h6> |
| |
| <p> 1.1. This document is intended to solve two related problems. First, |
| defining the ABI and runtime environment for applications using |
| OpenGL under X11 on Linux. This will enable applications using the |
| OpenGL API for rendering to run on a variety of underlying |
| implementations transparently. The intent is to address all of open |
| source, commercial closed binary, OpenGL SI-based, and Mesa-based |
| implementations. </p> |
| |
| <p> Second, defining the SDK for developing apps using OpenGL. This |
| includes header file locations, conventions for use of extensions, |
| etc. </p> |
| |
| <p> It has similar goals to the <a href="http://www.linuxbase.org">Linux |
| Standard Base</a>, but focused much |
| more narrowly: on the OpenGL API. Representatives from LSB are |
| involved and ultimately this effort should be part of LSB. </p> |
| |
| <p> We do not exactly track all LSB practice (particularly naming |
| conventions for libraries) because LSB itself is not complete, and |
| because existing practice with other OpenGL implementations suggests |
| preferred methods which may differ from LSB. </p> |
| |
| <p> 1.2. Things we do <b>not</b> attempt to address include: </p> |
| |
| <ul> |
| <li> Internal implementation dependent issues - details of direct |
| rendering, loadable driver modules, etc. Such details are |
| hidden from the public interfaces by the implementation, |
| and are irrelevant to applications using the ABI. </li> |
| <li> Operating systems other than Linux. Other platforms such as BSD |
| are welcome to use whatever comes out of this project, but we |
| are explicitly not trying to solve this problem for every free |
| OS in the world. </li> |
| <li> Changes to the OpenGL API. The definition of OpenGL is |
| controlled by the OpenGL Architecture Review Board, and we in no |
| way challenge this. A single GLX extension is required; this |
| extension has already been approved by the ARB. </li> |
| <li> Use of 3D outside the X11/GLX context. There are a variety of |
| approaches (fxMesa, GGI, etc.) that again are welcome to use |
| relevant parts of this project, but whose support is not part of |
| its goals. </li> |
| </ul> |
| |
| <p> 1.3. We believe all critical decisions have been made. Some |
| remaining comments (previously identified as open issues) of |
| interest are identified in the <a href="#app">appendix</a>. We |
| recognize that some decisions are largely arbitrary (filenames and |
| file locations, for example) and in those cases have been guided by |
| existing practice (<i>in other words, complaining about arbitrary |
| decisions is unlikely to change them</i>). </p> |
| |
| <p> 1.4. Participants in this effort to date include people working at |
| or involved with the following companies and open source projects |
| (as well as a large number of individuals with unknown |
| affiliations): </p> |
| |
| <blockquote> |
| 3Dfx, Alias/Wavefront, Apple, Avid, Compaq, Debian, HP, IBM, Intel, |
| Linux Standard Base, Loki Games, Mesa, Metro Link, NVIDIA, Nichimen, |
| Parametric Technology Corporation, Precision Insight, SGI, Sharp |
| Eye, Sun, XFree86, Xi Graphics.</blockquote> |
| |
| <p> <a name="2"></a></p> |
| <h6>2. Calling Conventions</h6> |
| |
| <p> 2.1. OpenGL already includes its own datatypes (<tt>GLint, |
| GLshort,</tt> etc.) used in the API. Guaranteed minimum sizes are |
| stated (see table 2.2 of the OpenGL 1.2 Specification), but the |
| actual choice of C datatype is left to the implementation. For our |
| purposes, however, all implementations on a given binary |
| architecture must have common definitions of these datatypes. </p> |
| |
| <p> For the IA32 architecture, the definitions should be: </p> |
| |
| <table border="1" class="center-table"> |
| <tr><td>GL datatype</td> |
| <td>Description</td> |
| <td>gcc equivalent for IA32</td></tr> |
| <tr><td><tt>GLboolean</tt></td> |
| <td>8-bit boolean</td> |
| <td><tt>unsigned char</tt></td></tr> |
| <tr><td><tt>GLbyte</tt></td> |
| <td>signed 8-bit 2's-complement integer</td> |
| <td><tt>signed char</tt></td></tr> |
| <tr><td><tt>GLubyte</tt></td> |
| <td>unsigned 8-bit integer</td> |
| <td><tt>unsigned char</tt></td></tr> |
| <tr><td><tt>GLshort</tt></td> |
| <td>signed 16-bit 2's-complement integer</td> |
| <td><tt>short</tt></td></tr> |
| <tr><td><tt>GLushort</tt></td> |
| <td>unsigned 16-bit integer</td> |
| <td><tt>unsigned short</tt></td></tr> |
| <tr><td><tt>GLint</tt></td> |
| <td>signed 32-bit 2's-complement integer</td> |
| <td><tt>int</tt></td></tr> |
| <tr><td><tt>GLuint</tt></td> |
| <td>unsigned 32-bit integer</td> |
| <td><tt>unsigned int</tt></td></tr> |
| <tr><td><tt>GLsizei</tt></td> |
| <td>non-negative 32-bit binary integer size</td> |
| <td><tt>int</tt></td></tr> |
| <tr><td><tt>GLenum</tt></td> |
| <td>enumerated 32-bit value</td> |
| <td><tt>unsigned int</tt></td></tr> |
| <tr><td><tt>GLbitfield</tt></td> |
| <td>32 bit bitfield</td> |
| <td><tt>unsigned int</tt></td></tr> |
| <tr><td><tt>GLfloat</tt></td> |
| <td>32-bit IEEE754 floating-point</td> |
| <td><tt>float</tt></td></tr> |
| <tr><td><tt>GLclampf</tt></td> |
| <td>Same as GLfloat, but in range [0, 1]</td> |
| <td><tt>float</tt></td></tr> |
| <tr><td><tt>GLdouble</tt></td> |
| <td>64-bit IEEE754 floating-point</td> |
| <td><tt>double</tt></td></tr> |
| <tr><td><tt>GLclampd</tt></td> |
| <td>Same as GLdouble, but in range [0, 1]</td> |
| <td><tt>double</tt></td></tr> |
| </table> |
| |
| <p> <a href="#issue2.1">Issues</a></p> |
| |
| <p> 2.2. Assembly-level call conventions must be shared. Since the |
| OpenGL implementation may use C++ code internally (e.g. for GLU), |
| this is potentially a serious problem. Static linking of C++ |
| libraries used by OpenGL libraries may be required of the |
| implementation (also see the <a href="#3">Libraries</a> section |
| below). </p> |
| |
| <p> <a href="#issue2.2">Issues</a> </p> |
| |
| <p> <a name="3"></a></p> |
| <h6>3. Libraries</h6> |
| |
| <p> 3.1. There are two link-level libraries. <tt>libGL</tt> includes the |
| OpenGL and GLX entry points and in general depends on underlying |
| hardware and/or X server dependent code that may or may not be |
| incorporated into this library. <tt>libGLU</tt> includes the GLU |
| utility routines and should be hardware independent, using only the |
| OpenGL API. </p> |
| |
| <p> Each library has two names: the link name used |
| on the ld command line, and the <tt>DT_SONAME</tt> within that |
| library (specified by the <i>-soname</i> switch when linking the |
| library), defining where it's looked up at runtime. Both forms must |
| exist so that both linking and running will operate properly. The |
| library names are: </p> |
| |
| <table cellspacing="1" border="1" class="center-table"> |
| <tr><td>Link name</td> |
| <td>Runtime name (<tt>DT_SONAME</tt>)</td> |
| </tr> |
| <tr><td><tt>libGL.so<tt></td> |
| <td><tt>libGL.so.1<tt></td> |
| </tr> |
| <tr><td><tt>libGLU.so<tt></td> |
| <td><tt>libGLU.so.1<tt></td> |
| </tr> |
| </table> |
| |
| <p> <tt>libGL.so</tt> and <tt>libGLU.so</tt> should |
| be symbolic links pointing to the runtime names, so that |
| future versions of the standard can be implemented transparently |
| to applications by changing the link. </p> |
| |
| <p> <a href="#issue3.1">Issues</a> </p> |
| |
| <p> 3.2. These libraries must be located in <tt>/usr/lib</tt>. The |
| X-specific library direction (<tt>/usr/lib/X11</tt>) was also |
| considered, but existing practice on Linux and other platforms |
| indicates that <tt>/usr/lib</tt> is preferable. </p> |
| |
| <p> <a href="#issue3.2">Issues</a> |
| |
| <p> 3.3. C++ runtime environments are likely to be incompatible |
| cross-platform, including both the standard C++ library location and |
| entry points, and the semantics of issues such as static |
| constructors and destructors. The LSB apparently mandates static |
| linking of libraries which aren't already in LSB, but this could |
| lead to problems with multiple C++ RTLs present in the same app |
| using C++. We'll have to tread carefully here until this issue |
| is more completely understood. </p> |
| |
| <p> <a href="#issue3.3">Issues</a> </p> |
| |
| <p> 3.4. The libraries must export all OpenGL 1.2, |
| GLU 1.3, GLX 1.3, and <tt>ARB_multitexture</tt> entry points |
| statically. </p> |
| |
| <p> It's possible (but unlikely) that additional ARB or vendor |
| extensions will be mandated before the ABI is finalized. |
| Applications should not expect to link statically against any entry |
| points not specified here. </p> |
| |
| <p> 3.5. Because non-ARB extensions vary so widely and are constantly |
| increasing in number, it's infeasible to require that they all be |
| supported, and extensions can always be added to hardware drivers |
| after the base link libraries are released. These drivers are |
| dynamically loaded by <tt>libGL</tt>, so extensions not in the base |
| library must also be obtained dynamically. </p> |
| |
| <p> 3.6. To perform the dynamic query, |
| <tt>libGL</tt> also must export an entry point called </p> |
| |
| <blockquote> |
| <tt>void (*glXGetProcAddressARB(const GLubyte *))();</tt> |
| </blockquote> |
| |
| <p> The <a href="http://www.opengl.org/registry/specs/ARB/get_proc_address.txt">full specification</a> |
| of this function is available separately. It takes the string name |
| of a GL or GLX entry point and returns a pointer to a function |
| implementing that entry point. It is functionally identical to the |
| <tt>wglGetProcAddress</tt> query defined by the Windows OpenGL |
| library, except that the function pointers returned are <i>context |
| independent</i>, unlike the WGL query. </p> |
| |
| <p> All OpenGL and GLX entry points may be queried with this extension; |
| GLU extensions cannot, because GLU is a client-side library that |
| cannot easily be extended. </p> |
| |
| <p> <a href="#issue3.6">Issues</a> </p> |
| |
| <p> 3.7. Thread safety (the ability to issue OpenGL calls to different |
| graphics contexts from different application threads) is required. |
| Multithreaded applications must use <b>-lpthread</b>. </p> |
| |
| <p> 3.8. <tt>libGL</tt> and <tt>libGLU</tt> must be |
| transitively linked with any libraries they require in their own |
| internal implementation, so that applications don't fail on some |
| implementations due to not pulling in libraries needed not by the |
| app, but by the implementation. </p> |
| |
| <p> <a name="4"></a></p> |
| <h6>4. Header Files</h6> |
| |
| <p> 4.1. The following header files are required: </p> |
| |
| <ul> |
| <li> <tt><GL/gl.h></tt> - OpenGL </li> |
| <li> <tt><GL/glx.h></tt> - GLX </li> |
| <li> <tt><GL/glu.h></tt> - GLU </li> |
| <li> <tt><GL/glext.h></tt> - OpenGL Extensions </li> |
| <li> <tt><GL/glxext.h></tt> - GLX Extensions </li> |
| </ul> |
| |
| <p> These headers should properly define prototypes and enumerants for |
| use by applications written in either C or C++. Other language |
| bindings are not addressed at this time. </p> |
| |
| <p> 4.2. These header files must be located in <tt>/usr/include/GL</tt>. |
| <tt>/usr/include/X11/GL</tt> was considered and rejected for the |
| same reasons as library locations in section 3.2 above. </p> |
| |
| <p> 4.3. The required headers must not pull in |
| internal headers or headers from other packages where that would |
| cause unexpected namespace pollution (for example, on IRIX |
| <tt>glx.h</tt> pulls in <tt><X11/Xmd.h></tt>). Likewise the |
| required headers must be protected against multiple inclusion and |
| should not themselves include any headers that are not so protected. |
| However, <tt>glx.h</tt> is allowed to include |
| <tt><X11/Xlib.h></tt> and <tt><X11/Xutil.h></tt>. </p> |
| |
| <p> 4.4. <tt>glx.h</tt> must include the prototype of the |
| <tt>glXGetProcAddressARB</tt> extension described above. </p> |
| |
| <p> 4.5. All OpenGL 1.2 and <tt>ARB_multitexture</tt>, GLU 1.3, and GLX |
| 1.3 entry points and enumerants must be present in the corresponding |
| header files <tt>gl.h</tt>, <tt>glu.h</tt>, and <tt>glx.h</tt>, |
| <b>even if</b> only OpenGL 1.1 is implemented at runtime by the |
| associated runtime libraries. </p> |
| |
| <p> <a href="#issue4.5">Issues</a> </p> |
| |
| <p> 4.6. Non-ARB OpenGL extensions are |
| defined in <tt>glext.h</tt>, and non-ARB GLX extensions in |
| <tt>glxext.h</tt>. If these extensions are also defined in one of |
| the other required headers, this must be done conditionally so that |
| multiple definition problems don't occur. </p> |
| |
| <p> <a href="#issue4.6">Issues</a> </p> |
| |
| <p> 4.7. Vendor-specific shortcuts, such as macros for higher |
| performance GL entry points, are intrinsically unportable. These |
| should <b>not</b> be present in the required header files, but |
| instead in a vendor-specific header file that requires explicit |
| effort to access, such as defining a vendor-specific preprocessor |
| symbol. Likewise vendors who are not willing to include their |
| extensions in <tt>glext.h</tt> must isolate those extensions in |
| vendor-specific headers. </p> |
| |
| <p> 4.8. <tt>gl.h</tt> must define the symbol |
| <tt>GL_OGLBASE_VERSION</tt>. This symbol must be an integer defining |
| the version of the ABI supported by the headers. Its value is |
| <i>1000 * major_version + minor_version</i> where |
| <i>major_version</i> and <i>minor_version</i> are the major and |
| minor revision numbers of this ABI standard. The primary purpose of |
| the symbol is to provide a compile-time test by which application |
| code knows whether the ABI guarantees are in force. </p> |
| |
| <p> <a href="#issue4.8">Issues</a> </p> |
| |
| <p> <a name="5"></a></p> |
| <h6>5. Extension Headers</h6> |
| |
| <p> 5.1. Providing prototypes and enumerants for OpenGL extensions is |
| challenging because of the expected wide variety of hardware |
| drivers, continuing creation of extensions, and multiple sources of |
| header files on Linux OpenGL implementations. Some extensions will |
| be supported only for a specific implementation, and some will be |
| supported only for a specific hardware driver within that |
| implementation. This situation does not lend itself easily to |
| independent maintenance of header files definining the extensions. |
| </p> |
| |
| <p> Instead, we require a single header file defining <b>all</b> OpenGL |
| extensions be supplied from a central point and updated on a |
| continuing basis as new extensions are added to the OpenGL <a |
| href="http://www.opengl.org/registry/">extension registry</a> (which |
| is similarly centrally maintained). The central point is in the |
| registry at <a href="http://www.opengl.org/registry/"> |
| http://www.opengl.org/registry/</a>. </p> |
| |
| <p> The <a href="../api/glext.h">latest version of |
| <tt>glext.h</tt></a> is available in the registry. It is |
| automatically generated from the master OpenGL function and |
| enumerant registries, and is updated as new extensions are |
| registered. The header is intended to be useful on other platforms |
| than Linux, particularly Windows; please let us know (via feedback |
| to OpenGL.org forums) if it needs enhancement for use on another |
| platform. The generator scripts and ".spec" files used in |
| generating glext.h are also available. </p> |
| |
| <p> Likewise for GLX, a single header defining |
| all GLX extensions, <a href="../api/glxext.h"><tt>glxext.h</tt></a>, |
| is required and is maintained centrally. </p> |
| |
| <p> The registry also contains a header defining WGL |
| extensions, <a href="../api/wglext.h"><tt>wglext.h</tt></a>, but this is |
| only for use on Windows; <tt>wglext.h</tt> is <b>not</b> required by |
| or useful for the Linux ABI. </p> |
| |
| <p> <a href="#issue5.1">Issues</a> </p> |
| |
| <p> 5.2. The centrally maintained <tt>glext.h</tt> will be continually |
| updated, so version creep is expected. This could cause problems for |
| open source projects distributing source code. The proper solution |
| is for users to update glext.h to the latest version, but versioning |
| has proven helpful with other extensible aspects of OpenGL. |
| Therefore <tt>glext.h</tt> must include a preprocessor version |
| symbol <tt>GL_GLEXT_VERSION</tt>, enabling apps to do something |
| like: </p> |
| |
| <blockquote> |
| <tt> |
| #include <GL/glext.h><br> |
| #if GL_GLEXT_VERSION < 42<br> |
| #error "I need a newer <GL/glext.h>. Please download it from http://www.opengl.org/registry/ABI/"<br> |
| #endif |
| </tt> |
| </blockquote> |
| |
| <p> <a href="#issue5.2">Issues</a> </p> |
| |
| <p> 5.3. Only extensions whose fully documented specifications have been |
| made available to the extension registry and whose authors have |
| committed to shipping them in their drivers will be included in |
| <tt>glext.h</tt> and <tt>glxext.h</tt>. The structure of each |
| extension defined in these headers should resemble: </p> |
| |
| <blockquote> |
| <tt> |
| #ifndef GL_EXT_<i>extensionname</i><br> |
| #define GL_EXT_<i>extensionname</i> 1<br> |
| <i> Define enumerants specific to this extension</i><br> |
| <i> Typedef function pointers for entry points specifically to |
| this extension, dynamically obtained |
| with glXGetProcAddressARB</i><br> |
| #ifdef GL_GLEXT_PROTOTYPES<br> |
| <i> Define prototypes specific to this extension</i><br> |
| #endif<br> |
| #endif |
| </tt> |
| </blockquote> |
| |
| <p> Benign redefinition of the enumerants is allowable, so these may be |
| outside protective <tt>#ifndef</tt> statements (this structure |
| results from the generator scripts used in the OpenGL SI to build |
| <tt>glext.h</tt>, and also because some enums may be defined by |
| multiple different extensions, so it could make sense to segregate |
| them). </p> |
| |
| <p> Function pointer typedefs will use the Windows convention (e.g. the |
| typedef for a function <tt>glFooARB</tt> will be |
| <tt>PFNGLFOOARBPROC</tt>) for application source code portability. |
| </p> |
| |
| <p> Normally, prototypes are present in |
| the header files, but are not visible due to conditional compilation. |
| To define prototypes as well as typedefs, the application must |
| <tt>#define GL_GLEXT_PROTOTYPES</tt> prior to including |
| <tt>gl.h</tt> or <tt>glx.h</tt>. <i>(Note: consistency suggests |
| using <tt>GLX_GLXEXT_PROTOTYPES</tt> for <tt>glxext.h</tt> - |
| TBD)</i>. </p> |
| |
| <p> The preprocessor symbol protecting the extension declaration |
| must be the same as the name string identifying the extension at |
| runtime and in the extension registry. </p> |
| |
| <p> <b>All</b> OpenGL and GLX extensions that are shipping should have a |
| full extension specification in the master |
| <a href="http://www.opengl.org/registry"> |
| extension registry</a> on www.opengl.org. Vendors failing to document |
| and specify their on extensions will not be allowed to incorporate |
| the resulting inadequate interfaces into the ABI. </p> |
| |
| <p> <a href="#issue5.3">Issues</a> </p> |
| |
| <p> 5.4. <tt>glext.h</tt> is normally |
| <tt>#include</tt>ed by <tt>gl.h</tt>. This inclusion can be |
| suppressed by the application defining the preprocessor symbol |
| <tt>GL_GLEXT_LEGACY</tt> prior to its <tt>#include |
| <GL/gl.h></tt>. </p> |
| |
| <p> <img src="new.gif">Similarly, <tt>glxext.h</tt> is normally |
| <tt>#include</tt>ed by <tt>glx.h</tt>. This inclusion can be |
| suppressed by the application defining the preprocessor symbol |
| <tt>GLX_GLXEXT_LEGACY</tt> prior to its <tt>#include |
| <GL/glx.h></tt>. </p> |
| |
| <p> <a href="#issue5.4">Issues</a> </p> |
| |
| <p> <a name="6"></a></p> |
| <h6>6. Feedback and Mailing Lists</h6> |
| |
| <p> Since the ABI has been finalized, we are no longer maintaining the |
| oglbase-discuss mailing list used during its development. List |
| archives may still be available from |
| <a href="http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/"> |
| http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/</a> </p> |
| |
| <hr/> |
| |
| <p> <a name="app"></a></p> |
| <h6>Appendix: Open Issues</h6> |
| |
| <p> <a name="issue2.1"></a> |
| <b>Section 2.1</b>: |
| Define GL datatypes for other supported Linux architectures - Alpha, |
| PowerPC, MIPS, etc. (in general these will be identical to the IA32 |
| types). Note: we may want to suggest <tt>GLlong</tt> and |
| <tt>GLulong</tt> as 64-bit datatypes for future OpenGL revisions. </p> |
| |
| <p> <a name="issue2.2"></a> |
| <b>Section 2.2</b>: |
| C++ libraries at runtime can be problematic - take the gcc/egcs |
| split, for example. Another potential problem area is static |
| constructor/destructor issues, e.g. when a C <tt>main()</tt> is |
| linked against GLU. Some tweaking may be required as apps running |
| against different ABI revisions start appearing. </p> |
| |
| <p> <a name="issue3.1"></a> |
| <b>Section 3.1</b>: |
| LSB uses a more complex naming convention for libraries; we're |
| avoiding this at least for now, because these conventions disagree |
| with common practice on virtually all other Unix OpenGL |
| implementations. </p> |
| |
| <p> <a name="issue3.2"></a> |
| <b>Section 3.2 (also Section 4.1)</b>: |
| Placing the headers and libraries in non-X11 specific locations |
| could impact non-GLX OpenGL implementations resident on the same |
| platform. It is also somewhat out of keeping with other X |
| extensions. However, this practice is so common on other platforms, |
| and non-X based OpenGL implementations are so rarely used, that we |
| chose to do so for build portability and "principle of least |
| surprise" purposes. </p> |
| |
| <p> Nothing prohibits the implementation from |
| placing the actual library files in other locations and implementing |
| the required library paths as links. </p> |
| |
| <p> <a name="issue3.3"></a> |
| <b>Section 3.3</b>: |
| The ABI should probably state requirements on GL libraries using C++ |
| or other auxiliary libraries, such that no conflict will arise with |
| apps also using those libraries. </p> |
| |
| <p> <a name="issue3.6"></a> |
| <b>Section 3.6</b>: |
| The context-independence requirement was the subject of enormous |
| controversy, mostly because the consequences of this requirement on |
| the underlying link library and driver implementations can be |
| significant. It is impossible to briefly recap the many pro and con |
| arguments briefly; refer to the <a href="#6">mailing list |
| archive</a> to learn more. </p> |
| |
| <p> GLU does sometimes need to be extended to |
| properly support new GL extensions; in particular, new pixel formats |
| and types, or new targets for texture downloads, such as cube |
| mapping, should ideally be exposed through the GLU mipmap generation |
| routines. This is an unresolved problem, since GLU is client code |
| not specific to any GL driver and thus not dynamically loadable. The |
| best current option is for driver suppliers to make sure that |
| whatever GLU functionality they need is contributed to the OpenGL |
| Sample Implementation's GLU library. </p> |
| |
| <p> Portable applications should treat the pointers |
| as context-dependent. </p> |
| |
| <p> We haven't determined if any non-ARB extensions should be standard |
| entry points not requiring this dynamic lookup. As a reference |
| point, here are lists of GL, GLX, and GLU extensions supported by a |
| variety of OpenGL and Mesa implementations today (please send |
| additions for other platforms to the oglbase-discuss mailing list so |
| they can be added): </p> |
| |
| <ul> |
| <li><a href="ext/3dlabs.txt">3Dlabs</a> </li> |
| <li><a href="ext/compaq.txt">Compaq</a> </li> |
| <li><a href="ext/intergraph.txt">Intergraph/Intense 3D</a> </li> |
| <li><a href="ext/mesa.txt">Mesa</a> </li> |
| <li><a href="ext/sgi.txt">SGI (multiple platforms)</a> </li> |
| <li><a href="ext/sun_ultra.txt">Sun Ultra</a> </li> |
| <li><a href="ext/xig.txt">Xi Graphics</a> </li> |
| </ul> |
| |
| <p> <a name="issue4.5"></a> |
| <b>Section 4.5</b>: |
| Implementations may still implement only OpenGL 1.1 functionality, |
| but the 1.2 header and link library material must still be provided. |
| Since applications must already check both compile and runtime |
| OpenGL version numbers, no problems due to lacking support for 1.2 |
| are expected. The next version of this standard is anticipated to |
| require OpenGL 1.2 support. </p> |
| |
| <p> <a name="issue4.6"></a> |
| <b>Section 4.6</b>: |
| It's important that <tt>glext.h</tt> and <tt>glxext.h</tt> can be |
| updated from the extension registry without breaking <tt>gl.h</tt> |
| and <tt>glx.h</tt>. Making sure that all extension definitions are |
| properly protected helps to this end, as well as being good |
| programming practice. </p> |
| |
| <p> <a name="issue4.8"></a> |
| <b>Section 4.8</b>: |
| <tt>GL_OGLBASE_VERSION</tt> is mostly provided so that apps can |
| determine whether to use traditional static linking of extensions, |
| or to dynamically query them. Unlike GL/GLX versioning, the ABI |
| version is not dynamically queryable at runtime. Historical |
| experience suggests that not providing the runtime query to begin |
| with is a bad decision. </p> |
| |
| <p> <a name="issue5.1"></a> |
| <b>Section 5.1</b>: |
| <tt>glext.h</tt> is an exception to the Linux-centric nature of this |
| document, since it is already being used on other platforms. </p> |
| |
| <p> <a name="issue5.2"></a> |
| <b>Section 5.2</b>: |
| Applications should <b>not</b> use the version number in |
| <tt>glext.h</tt> to test for presence or absence of specific |
| extension prototypes; this is extremely unportable and dangerous. |
| Always use the extension-specific symbols described in section 5.3. |
| </p> |
| |
| <p> The header version symbol was changed from |
| <tt>GL_GLEXT_VERSION_EXT</tt> to <tt>GL_GLEXT_VERSION</tt> for |
| consistency with the <tt>GLEXT</tt> namespace the ABI group has |
| started using. </p> |
| |
| <p> <a name="issue5.3"></a> |
| <b>Section 5.3</b>: |
| Other structures for the extension prototypes have been suggested, |
| such as having separate header files for each extension. Having both |
| structures may be preferable, but it requires more work. </p> |
| |
| <p> <a name="issue5.4"></a> |
| <b>Section 5.4</b>: |
| It's important to be able to suppress automatic inclusion of |
| <tt>glext.h</tt> and <tt>glxext.h</tt> in order to support |
| compilation of legacy code not written to be ABI-aware (e.g. |
| assuming that extensions can be statically linked). </p> |
| |
| <p> <a name="log"></a></p> |
| <h6>7. Change Log</h6> |
| |
| <ul> |
| <li> 10/9/2006 - updated registry links to the new location on |
| opengl.org and cleaned up other dangling wording due to the move |
| from oss.sgi.com. |
| <li> 6/20/2000 (version 1.0) - Linux ABI approved on the oglbase-discuss |
| mailing list. Corrected Windows function-pointer typedef convention |
| in section 5.3 by appending <tt>PROC</tt>, to match what glext.h |
| already does. </li> |
| <li> 5/29/2000 (version 0.9.8) - <tt>glxext.h</tt> added to section 4. |
| Resolution reached on the structure of <tt>glext.h</tt> and |
| <tt>glxext.h</tt>, and how they are included from <tt>gl.h</tt> and |
| <tt>glx.h</tt>. In particular, <tt>GL_OGLBASE_VERSION</tt> symbol |
| defined, default inclusion of extension headers from core headers |
| mandated, <tt>GL_GLEXT_PROTOTYPES</tt> may be specified in order to |
| get extension prototypes as well as function pointer typedefs. |
| Renamed <tt>GL_GLEXT_VERSION_EXT</tt> to <tt>GL_GLEXT_VERSION</tt>. |
| </li> |
| <li> 4/9/2000 (version 0.9.7) - <tt>glext.h</tt> is now available |
| together with the ABI specification. </li> |
| <li> 2/22/2000 (version 0.9.6) - Revised for public comment period. |
| Moved open issues to the new appendix. </li> |
| <li> 2/8/2000 (version 0.9.5) - Removed ellipses from prototype in |
| section 3.6, and simplified the lists of SGI supported extensions |
| into one file. Mandated threadsafety in section 3.7. Moved |
| glXGetProcAddressARB prototype from gl.h to glx.h in section 4.4, |
| since the function itself was moved from gl to glX during |
| standardization. Restructured the page to fit into the ogl-sample |
| site on oss.sgi.com, next to the extension registry. Pointed to the |
| updated extension registry on oss.sgi.com in several places. </li> |
| <li> 12/9/99 (version 0.9.4) - Added Intergraph extension list in |
| section 3.6. </li> |
| <li> 12/6/99 (version 0.9.3) - Added Compaq and 3Dlabs extension |
| lists in section 3.6. </li> |
| <li> 11/23/99 (version 0.9.2) - Refined discussion of |
| glXGetProcAddressARB to specify that any GL or GLX function can be |
| queried. </li> |
| <li> 11/23/99 (version 0.9.1) - Summing up lots of email discussion. |
| Expanded participant list in section 1.4. Pinned down library |
| naming scheme in section 3.1. Changed to require statically |
| exporting all GL 1.2 / GLX 1.3 / GLU 1.3 / ARB extension entry |
| points in section 3.4. Changed GetProcAddress from EXT to ARB and |
| from gl to glX(in anticipation of ARB approval) in section 3.5. |
| Does <b>not</b> require a context parameter. Require Windows naming |
| convention for <tt>glext.h</tt> function prototypes in section 5.3. |
| Added a link to the list archives in section 6. </li> |
| <li> 9/16/1999 - Added Mesa, Sun, and Xi Graphics extension lists in |
| section 3.6. Added section 3.8 on transitive library dependencies |
| of the GL libraries. </li> |
| <li> 9/10/1999 - Added initial list of GL/GLX/GLU extensions |
| for existing platforms in section 3.6.<br> |
| Specified text/link colors as well as background color. </li> |
| <li> 9/7/1999 - Initial version. </li> |
| </ul> |
| |
| <?php include_once("../../../assets/static_pages/khr_page_bottom.php"); ?> |
| </body> |
| </html> |