1<?php 2$static_title = 'OpenGL® Application Binary Interface for Linux'; 3$static_breadcrumb = array( 4 '/registry/' => 'Registry', 5 '/registry/OpenGL' => 'OpenGL', 6 'NOLINK' => 'ABI' 7); 8include_once("../../../assets/static_pages/khr_page_top.php"); 9?> 10 11 12<h1 style="text-align:center"> 13 OpenGL® Application Binary Interface for Linux <br/> 14 <span style="font-size:12px"> (formerly Linux/OpenGL Base) </span> 15</h1> 16 17<p style="text-align:center">Version 1.0<br/> 18 Approved June 20, 2000<br/> 19 Editor: Jon Leech, SGI </p> 20 21<hr/> 22 23<h6>Latest News</h6> 24 25<p> Version 1.0 is complete. It was approved on June 20, 2000; all 26 submitted votes were in favor. </p> 27 28<hr/> 29 30<h6>Index</h6> 31 32 <ul> 33 <li><a href="#1">1. Overview and Goals </a></li> 34 <li><a href="#2">2. Calling Conventions</a></li> 35 <li><a href="#3">3. Libraries</a></li> 36 <li><a href="#4">4. Header Files</a></li> 37 <li><a href="#5">5. Extension Headers</a></li> 38 <li><a href="#6">6. Feedback and Mailing Lists</a></li> 39 <li><a href="#app">Appendix: Open Issues</a></li> 40 <li><a href="#log">Change Log</a></li> 41 </ul> 42 43<p> <a name="1"></a></p> 44<h6>1. Overview and Goals </h6> 45 46<p> 1.1. This document is intended to solve two related problems. First, 47 defining the ABI and runtime environment for applications using 48 OpenGL under X11 on Linux. This will enable applications using the 49 OpenGL API for rendering to run on a variety of underlying 50 implementations transparently. The intent is to address all of open 51 source, commercial closed binary, OpenGL SI-based, and Mesa-based 52 implementations. </p> 53 54<p> Second, defining the SDK for developing apps using OpenGL. This 55 includes header file locations, conventions for use of extensions, 56 etc. </p> 57 58<p> It has similar goals to the <a href="http://www.linuxbase.org">Linux 59 Standard Base</a>, but focused much 60 more narrowly: on the OpenGL API. Representatives from LSB are 61 involved and ultimately this effort should be part of LSB. </p> 62 63<p> We do not exactly track all LSB practice (particularly naming 64 conventions for libraries) because LSB itself is not complete, and 65 because existing practice with other OpenGL implementations suggests 66 preferred methods which may differ from LSB. </p> 67 68<p> 1.2. Things we do <b>not</b> attempt to address include: </p> 69 70 <ul> 71 <li> Internal implementation dependent issues - details of direct 72 rendering, loadable driver modules, etc. Such details are 73 hidden from the public interfaces by the implementation, 74 and are irrelevant to applications using the ABI. </li> 75 <li> Operating systems other than Linux. Other platforms such as BSD 76 are welcome to use whatever comes out of this project, but we 77 are explicitly not trying to solve this problem for every free 78 OS in the world. </li> 79 <li> Changes to the OpenGL API. The definition of OpenGL is 80 controlled by the OpenGL Architecture Review Board, and we in no 81 way challenge this. A single GLX extension is required; this 82 extension has already been approved by the ARB. </li> 83 <li> Use of 3D outside the X11/GLX context. There are a variety of 84 approaches (fxMesa, GGI, etc.) that again are welcome to use 85 relevant parts of this project, but whose support is not part of 86 its goals. </li> 87 </ul> 88 89<p> 1.3. We believe all critical decisions have been made. Some 90 remaining comments (previously identified as open issues) of 91 interest are identified in the <a href="#app">appendix</a>. We 92 recognize that some decisions are largely arbitrary (filenames and 93 file locations, for example) and in those cases have been guided by 94 existing practice (<i>in other words, complaining about arbitrary 95 decisions is unlikely to change them</i>). </p> 96 97<p> 1.4. Participants in this effort to date include people working at 98 or involved with the following companies and open source projects 99 (as well as a large number of individuals with unknown 100 affiliations): </p> 101 102 <blockquote> 103 3Dfx, Alias/Wavefront, Apple, Avid, Compaq, Debian, HP, IBM, Intel, 104 Linux Standard Base, Loki Games, Mesa, Metro Link, NVIDIA, Nichimen, 105 Parametric Technology Corporation, Precision Insight, SGI, Sharp 106 Eye, Sun, XFree86, Xi Graphics.</blockquote> 107 108<p> <a name="2"></a></p> 109<h6>2. Calling Conventions</h6> 110 111<p> 2.1. OpenGL already includes its own datatypes (<tt>GLint, 112 GLshort,</tt> etc.) used in the API. Guaranteed minimum sizes are 113 stated (see table 2.2 of the OpenGL 1.2 Specification), but the 114 actual choice of C datatype is left to the implementation. For our 115 purposes, however, all implementations on a given binary 116 architecture must have common definitions of these datatypes. </p> 117 118<p> For the IA32 architecture, the definitions should be: </p> 119 120<table border="1" class="center-table"> 121 <tr><td>GL datatype</td> 122 <td>Description</td> 123 <td>gcc equivalent for IA32</td></tr> 124 <tr><td><tt>GLboolean</tt></td> 125 <td>8-bit boolean</td> 126 <td><tt>unsigned char</tt></td></tr> 127 <tr><td><tt>GLbyte</tt></td> 128 <td>signed 8-bit 2's-complement integer</td> 129 <td><tt>signed char</tt></td></tr> 130 <tr><td><tt>GLubyte</tt></td> 131 <td>unsigned 8-bit integer</td> 132 <td><tt>unsigned char</tt></td></tr> 133 <tr><td><tt>GLshort</tt></td> 134 <td>signed 16-bit 2's-complement integer</td> 135 <td><tt>short</tt></td></tr> 136 <tr><td><tt>GLushort</tt></td> 137 <td>unsigned 16-bit integer</td> 138 <td><tt>unsigned short</tt></td></tr> 139 <tr><td><tt>GLint</tt></td> 140 <td>signed 32-bit 2's-complement integer</td> 141 <td><tt>int</tt></td></tr> 142 <tr><td><tt>GLuint</tt></td> 143 <td>unsigned 32-bit integer</td> 144 <td><tt>unsigned int</tt></td></tr> 145 <tr><td><tt>GLsizei</tt></td> 146 <td>non-negative 32-bit binary integer size</td> 147 <td><tt>int</tt></td></tr> 148 <tr><td><tt>GLenum</tt></td> 149 <td>enumerated 32-bit value</td> 150 <td><tt>unsigned int</tt></td></tr> 151 <tr><td><tt>GLbitfield</tt></td> 152 <td>32 bit bitfield</td> 153 <td><tt>unsigned int</tt></td></tr> 154 <tr><td><tt>GLfloat</tt></td> 155 <td>32-bit IEEE754 floating-point</td> 156 <td><tt>float</tt></td></tr> 157 <tr><td><tt>GLclampf</tt></td> 158 <td>Same as GLfloat, but in range [0, 1]</td> 159 <td><tt>float</tt></td></tr> 160 <tr><td><tt>GLdouble</tt></td> 161 <td>64-bit IEEE754 floating-point</td> 162 <td><tt>double</tt></td></tr> 163 <tr><td><tt>GLclampd</tt></td> 164 <td>Same as GLdouble, but in range [0, 1]</td> 165 <td><tt>double</tt></td></tr> 166</table> 167 168<p> <a href="#issue2.1">Issues</a></p> 169 170<p> 2.2. Assembly-level call conventions must be shared. Since the 171 OpenGL implementation may use C++ code internally (e.g. for GLU), 172 this is potentially a serious problem. Static linking of C++ 173 libraries used by OpenGL libraries may be required of the 174 implementation (also see the <a href="#3">Libraries</a> section 175 below). </p> 176 177<p> <a href="#issue2.2">Issues</a> </p> 178 179<p> <a name="3"></a></p> 180<h6>3. Libraries</h6> 181 182<p> 3.1. There are two link-level libraries. <tt>libGL</tt> includes the 183 OpenGL and GLX entry points and in general depends on underlying 184 hardware and/or X server dependent code that may or may not be 185 incorporated into this library. <tt>libGLU</tt> includes the GLU 186 utility routines and should be hardware independent, using only the 187 OpenGL API. </p> 188 189<p> Each library has two names: the link name used 190 on the ld command line, and the <tt>DT_SONAME</tt> within that 191 library (specified by the <i>-soname</i> switch when linking the 192 library), defining where it's looked up at runtime. Both forms must 193 exist so that both linking and running will operate properly. The 194 library names are: </p> 195 196<table cellspacing="1" border="1" class="center-table"> 197 <tr><td>Link name</td> 198 <td>Runtime name (<tt>DT_SONAME</tt>)</td> 199 </tr> 200 <tr><td><tt>libGL.so<tt></td> 201 <td><tt>libGL.so.1<tt></td> 202 </tr> 203 <tr><td><tt>libGLU.so<tt></td> 204 <td><tt>libGLU.so.1<tt></td> 205 </tr> 206</table> 207 208<p> <tt>libGL.so</tt> and <tt>libGLU.so</tt> should 209 be symbolic links pointing to the runtime names, so that 210 future versions of the standard can be implemented transparently 211 to applications by changing the link. </p> 212 213<p> <a href="#issue3.1">Issues</a> </p> 214 215<p> 3.2. These libraries must be located in <tt>/usr/lib</tt>. The 216 X-specific library direction (<tt>/usr/lib/X11</tt>) was also 217 considered, but existing practice on Linux and other platforms 218 indicates that <tt>/usr/lib</tt> is preferable. </p> 219 220<p> <a href="#issue3.2">Issues</a> 221 222<p> 3.3. C++ runtime environments are likely to be incompatible 223 cross-platform, including both the standard C++ library location and 224 entry points, and the semantics of issues such as static 225 constructors and destructors. The LSB apparently mandates static 226 linking of libraries which aren't already in LSB, but this could 227 lead to problems with multiple C++ RTLs present in the same app 228 using C++. We'll have to tread carefully here until this issue 229 is more completely understood. </p> 230 231<p> <a href="#issue3.3">Issues</a> </p> 232 233<p> 3.4. The libraries must export all OpenGL 1.2, 234 GLU 1.3, GLX 1.3, and <tt>ARB_multitexture</tt> entry points 235 statically. </p> 236 237<p> It's possible (but unlikely) that additional ARB or vendor 238 extensions will be mandated before the ABI is finalized. 239 Applications should not expect to link statically against any entry 240 points not specified here. </p> 241 242<p> 3.5. Because non-ARB extensions vary so widely and are constantly 243 increasing in number, it's infeasible to require that they all be 244 supported, and extensions can always be added to hardware drivers 245 after the base link libraries are released. These drivers are 246 dynamically loaded by <tt>libGL</tt>, so extensions not in the base 247 library must also be obtained dynamically. </p> 248 249<p> 3.6. To perform the dynamic query, 250 <tt>libGL</tt> also must export an entry point called </p> 251 252 <blockquote> 253 <tt>void (*glXGetProcAddressARB(const GLubyte *))();</tt> 254 </blockquote> 255 256<p> The <a href="http://www.opengl.org/registry/specs/ARB/get_proc_address.txt">full specification</a> 257 of this function is available separately. It takes the string name 258 of a GL or GLX entry point and returns a pointer to a function 259 implementing that entry point. It is functionally identical to the 260 <tt>wglGetProcAddress</tt> query defined by the Windows OpenGL 261 library, except that the function pointers returned are <i>context 262 independent</i>, unlike the WGL query. </p> 263 264<p> All OpenGL and GLX entry points may be queried with this extension; 265 GLU extensions cannot, because GLU is a client-side library that 266 cannot easily be extended. </p> 267 268<p> <a href="#issue3.6">Issues</a> </p> 269 270<p> 3.7. Thread safety (the ability to issue OpenGL calls to different 271 graphics contexts from different application threads) is required. 272 Multithreaded applications must use <b>-lpthread</b>. </p> 273 274<p> 3.8. <tt>libGL</tt> and <tt>libGLU</tt> must be 275 transitively linked with any libraries they require in their own 276 internal implementation, so that applications don't fail on some 277 implementations due to not pulling in libraries needed not by the 278 app, but by the implementation. </p> 279 280<p> <a name="4"></a></p> 281<h6>4. Header Files</h6> 282 283<p> 4.1. The following header files are required: </p> 284 285 <ul> 286 <li> <tt><GL/gl.h></tt> - OpenGL </li> 287 <li> <tt><GL/glx.h></tt> - GLX </li> 288 <li> <tt><GL/glu.h></tt> - GLU </li> 289 <li> <tt><GL/glext.h></tt> - OpenGL Extensions </li> 290 <li> <tt><GL/glxext.h></tt> - GLX Extensions </li> 291 </ul> 292 293<p> These headers should properly define prototypes and enumerants for 294 use by applications written in either C or C++. Other language 295 bindings are not addressed at this time. </p> 296 297<p> 4.2. These header files must be located in <tt>/usr/include/GL</tt>. 298 <tt>/usr/include/X11/GL</tt> was considered and rejected for the 299 same reasons as library locations in section 3.2 above. </p> 300 301<p> 4.3. The required headers must not pull in 302 internal headers or headers from other packages where that would 303 cause unexpected namespace pollution (for example, on IRIX 304 <tt>glx.h</tt> pulls in <tt><X11/Xmd.h></tt>). Likewise the 305 required headers must be protected against multiple inclusion and 306 should not themselves include any headers that are not so protected. 307 However, <tt>glx.h</tt> is allowed to include 308 <tt><X11/Xlib.h></tt> and <tt><X11/Xutil.h></tt>. </p> 309 310<p> 4.4. <tt>glx.h</tt> must include the prototype of the 311 <tt>glXGetProcAddressARB</tt> extension described above. </p> 312 313<p> 4.5. All OpenGL 1.2 and <tt>ARB_multitexture</tt>, GLU 1.3, and GLX 314 1.3 entry points and enumerants must be present in the corresponding 315 header files <tt>gl.h</tt>, <tt>glu.h</tt>, and <tt>glx.h</tt>, 316 <b>even if</b> only OpenGL 1.1 is implemented at runtime by the 317 associated runtime libraries. </p> 318 319<p> <a href="#issue4.5">Issues</a> </p> 320 321<p> 4.6. Non-ARB OpenGL extensions are 322 defined in <tt>glext.h</tt>, and non-ARB GLX extensions in 323 <tt>glxext.h</tt>. If these extensions are also defined in one of 324 the other required headers, this must be done conditionally so that 325 multiple definition problems don't occur. </p> 326 327<p> <a href="#issue4.6">Issues</a> </p> 328 329<p> 4.7. Vendor-specific shortcuts, such as macros for higher 330 performance GL entry points, are intrinsically unportable. These 331 should <b>not</b> be present in the required header files, but 332 instead in a vendor-specific header file that requires explicit 333 effort to access, such as defining a vendor-specific preprocessor 334 symbol. Likewise vendors who are not willing to include their 335 extensions in <tt>glext.h</tt> must isolate those extensions in 336 vendor-specific headers. </p> 337 338<p> 4.8. <tt>gl.h</tt> must define the symbol 339 <tt>GL_OGLBASE_VERSION</tt>. This symbol must be an integer defining 340 the version of the ABI supported by the headers. Its value is 341 <i>1000 * major_version + minor_version</i> where 342 <i>major_version</i> and <i>minor_version</i> are the major and 343 minor revision numbers of this ABI standard. The primary purpose of 344 the symbol is to provide a compile-time test by which application 345 code knows whether the ABI guarantees are in force. </p> 346 347<p> <a href="#issue4.8">Issues</a> </p> 348 349<p> <a name="5"></a></p> 350<h6>5. Extension Headers</h6> 351 352<p> 5.1. Providing prototypes and enumerants for OpenGL extensions is 353 challenging because of the expected wide variety of hardware 354 drivers, continuing creation of extensions, and multiple sources of 355 header files on Linux OpenGL implementations. Some extensions will 356 be supported only for a specific implementation, and some will be 357 supported only for a specific hardware driver within that 358 implementation. This situation does not lend itself easily to 359 independent maintenance of header files definining the extensions. 360 </p> 361 362<p> Instead, we require a single header file defining <b>all</b> OpenGL 363 extensions be supplied from a central point and updated on a 364 continuing basis as new extensions are added to the OpenGL <a 365 href="http://www.opengl.org/registry/">extension registry</a> (which 366 is similarly centrally maintained). The central point is in the 367 registry at <a href="http://www.opengl.org/registry/"> 368 http://www.opengl.org/registry/</a>. </p> 369 370<p> The <a href="../api/glext.h">latest version of 371 <tt>glext.h</tt></a> is available in the registry. It is 372 automatically generated from the master OpenGL function and 373 enumerant registries, and is updated as new extensions are 374 registered. The header is intended to be useful on other platforms 375 than Linux, particularly Windows; please let us know (via feedback 376 to OpenGL.org forums) if it needs enhancement for use on another 377 platform. The generator scripts and ".spec" files used in 378 generating glext.h are also available. </p> 379 380<p> Likewise for GLX, a single header defining 381 all GLX extensions, <a href="../api/glxext.h"><tt>glxext.h</tt></a>, 382 is required and is maintained centrally. </p> 383 384<p> The registry also contains a header defining WGL 385 extensions, <a href="../api/wglext.h"><tt>wglext.h</tt></a>, but this is 386 only for use on Windows; <tt>wglext.h</tt> is <b>not</b> required by 387 or useful for the Linux ABI. </p> 388 389<p> <a href="#issue5.1">Issues</a> </p> 390 391<p> 5.2. The centrally maintained <tt>glext.h</tt> will be continually 392 updated, so version creep is expected. This could cause problems for 393 open source projects distributing source code. The proper solution 394 is for users to update glext.h to the latest version, but versioning 395 has proven helpful with other extensible aspects of OpenGL. 396 Therefore <tt>glext.h</tt> must include a preprocessor version 397 symbol <tt>GL_GLEXT_VERSION</tt>, enabling apps to do something 398 like: </p> 399 400<blockquote> 401 <tt> 402 #include <GL/glext.h><br> 403 #if GL_GLEXT_VERSION < 42<br> 404 #error "I need a newer <GL/glext.h>. Please download it from http://www.opengl.org/registry/ABI/"<br> 405 #endif 406 </tt> 407</blockquote> 408 409<p> <a href="#issue5.2">Issues</a> </p> 410 411<p> 5.3. Only extensions whose fully documented specifications have been 412 made available to the extension registry and whose authors have 413 committed to shipping them in their drivers will be included in 414 <tt>glext.h</tt> and <tt>glxext.h</tt>. The structure of each 415 extension defined in these headers should resemble: </p> 416 417<blockquote> 418 <tt> 419 #ifndef GL_EXT_<i>extensionname</i><br> 420 #define GL_EXT_<i>extensionname</i> 1<br> 421 <i> Define enumerants specific to this extension</i><br> 422 <i> Typedef function pointers for entry points specifically to 423 this extension, dynamically obtained 424 with glXGetProcAddressARB</i><br> 425 #ifdef GL_GLEXT_PROTOTYPES<br> 426 <i> Define prototypes specific to this extension</i><br> 427 #endif<br> 428 #endif 429 </tt> 430</blockquote> 431 432<p> Benign redefinition of the enumerants is allowable, so these may be 433 outside protective <tt>#ifndef</tt> statements (this structure 434 results from the generator scripts used in the OpenGL SI to build 435 <tt>glext.h</tt>, and also because some enums may be defined by 436 multiple different extensions, so it could make sense to segregate 437 them). </p> 438 439<p> Function pointer typedefs will use the Windows convention (e.g. the 440 typedef for a function <tt>glFooARB</tt> will be 441 <tt>PFNGLFOOARBPROC</tt>) for application source code portability. 442 </p> 443 444<p> Normally, prototypes are present in 445 the header files, but are not visible due to conditional compilation. 446 To define prototypes as well as typedefs, the application must 447 <tt>#define GL_GLEXT_PROTOTYPES</tt> prior to including 448 <tt>gl.h</tt> or <tt>glx.h</tt>. <i>(Note: consistency suggests 449 using <tt>GLX_GLXEXT_PROTOTYPES</tt> for <tt>glxext.h</tt> - 450 TBD)</i>. </p> 451 452<p> The preprocessor symbol protecting the extension declaration 453 must be the same as the name string identifying the extension at 454 runtime and in the extension registry. </p> 455 456<p> <b>All</b> OpenGL and GLX extensions that are shipping should have a 457 full extension specification in the master 458 <a href="http://www.opengl.org/registry"> 459 extension registry</a> on www.opengl.org. Vendors failing to document 460 and specify their on extensions will not be allowed to incorporate 461 the resulting inadequate interfaces into the ABI. </p> 462 463<p> <a href="#issue5.3">Issues</a> </p> 464 465<p> 5.4. <tt>glext.h</tt> is normally 466 <tt>#include</tt>ed by <tt>gl.h</tt>. This inclusion can be 467 suppressed by the application defining the preprocessor symbol 468 <tt>GL_GLEXT_LEGACY</tt> prior to its <tt>#include 469 <GL/gl.h></tt>. </p> 470 471<p> <img src="new.gif">Similarly, <tt>glxext.h</tt> is normally 472 <tt>#include</tt>ed by <tt>glx.h</tt>. This inclusion can be 473 suppressed by the application defining the preprocessor symbol 474 <tt>GLX_GLXEXT_LEGACY</tt> prior to its <tt>#include 475 <GL/glx.h></tt>. </p> 476 477<p> <a href="#issue5.4">Issues</a> </p> 478 479<p> <a name="6"></a></p> 480<h6>6. Feedback and Mailing Lists</h6> 481 482<p> Since the ABI has been finalized, we are no longer maintaining the 483 oglbase-discuss mailing list used during its development. List 484 archives may still be available from 485 <a href="http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/"> 486 http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/</a> </p> 487 488<hr/> 489 490<p> <a name="app"></a></p> 491<h6>Appendix: Open Issues</h6> 492 493<p> <a name="issue2.1"></a> 494 <b>Section 2.1</b>: 495 Define GL datatypes for other supported Linux architectures - Alpha, 496 PowerPC, MIPS, etc. (in general these will be identical to the IA32 497 types). Note: we may want to suggest <tt>GLlong</tt> and 498 <tt>GLulong</tt> as 64-bit datatypes for future OpenGL revisions. </p> 499 500<p> <a name="issue2.2"></a> 501 <b>Section 2.2</b>: 502 C++ libraries at runtime can be problematic - take the gcc/egcs 503 split, for example. Another potential problem area is static 504 constructor/destructor issues, e.g. when a C <tt>main()</tt> is 505 linked against GLU. Some tweaking may be required as apps running 506 against different ABI revisions start appearing. </p> 507 508<p> <a name="issue3.1"></a> 509 <b>Section 3.1</b>: 510 LSB uses a more complex naming convention for libraries; we're 511 avoiding this at least for now, because these conventions disagree 512 with common practice on virtually all other Unix OpenGL 513 implementations. </p> 514 515<p> <a name="issue3.2"></a> 516 <b>Section 3.2 (also Section 4.1)</b>: 517 Placing the headers and libraries in non-X11 specific locations 518 could impact non-GLX OpenGL implementations resident on the same 519 platform. It is also somewhat out of keeping with other X 520 extensions. However, this practice is so common on other platforms, 521 and non-X based OpenGL implementations are so rarely used, that we 522 chose to do so for build portability and "principle of least 523 surprise" purposes. </p> 524 525<p> Nothing prohibits the implementation from 526 placing the actual library files in other locations and implementing 527 the required library paths as links. </p> 528 529<p> <a name="issue3.3"></a> 530 <b>Section 3.3</b>: 531 The ABI should probably state requirements on GL libraries using C++ 532 or other auxiliary libraries, such that no conflict will arise with 533 apps also using those libraries. </p> 534 535<p> <a name="issue3.6"></a> 536 <b>Section 3.6</b>: 537 The context-independence requirement was the subject of enormous 538 controversy, mostly because the consequences of this requirement on 539 the underlying link library and driver implementations can be 540 significant. It is impossible to briefly recap the many pro and con 541 arguments briefly; refer to the <a href="#6">mailing list 542 archive</a> to learn more. </p> 543 544<p> GLU does sometimes need to be extended to 545 properly support new GL extensions; in particular, new pixel formats 546 and types, or new targets for texture downloads, such as cube 547 mapping, should ideally be exposed through the GLU mipmap generation 548 routines. This is an unresolved problem, since GLU is client code 549 not specific to any GL driver and thus not dynamically loadable. The 550 best current option is for driver suppliers to make sure that 551 whatever GLU functionality they need is contributed to the OpenGL 552 Sample Implementation's GLU library. </p> 553 554<p> Portable applications should treat the pointers 555 as context-dependent. </p> 556 557<p> We haven't determined if any non-ARB extensions should be standard 558 entry points not requiring this dynamic lookup. As a reference 559 point, here are lists of GL, GLX, and GLU extensions supported by a 560 variety of OpenGL and Mesa implementations today (please send 561 additions for other platforms to the oglbase-discuss mailing list so 562 they can be added): </p> 563 564 <ul> 565 <li><a href="ext/3dlabs.txt">3Dlabs</a> </li> 566 <li><a href="ext/compaq.txt">Compaq</a> </li> 567 <li><a href="ext/intergraph.txt">Intergraph/Intense 3D</a> </li> 568 <li><a href="ext/mesa.txt">Mesa</a> </li> 569 <li><a href="ext/sgi.txt">SGI (multiple platforms)</a> </li> 570 <li><a href="ext/sun_ultra.txt">Sun Ultra</a> </li> 571 <li><a href="ext/xig.txt">Xi Graphics</a> </li> 572 </ul> 573 574<p> <a name="issue4.5"></a> 575 <b>Section 4.5</b>: 576 Implementations may still implement only OpenGL 1.1 functionality, 577 but the 1.2 header and link library material must still be provided. 578 Since applications must already check both compile and runtime 579 OpenGL version numbers, no problems due to lacking support for 1.2 580 are expected. The next version of this standard is anticipated to 581 require OpenGL 1.2 support. </p> 582 583<p> <a name="issue4.6"></a> 584 <b>Section 4.6</b>: 585 It's important that <tt>glext.h</tt> and <tt>glxext.h</tt> can be 586 updated from the extension registry without breaking <tt>gl.h</tt> 587 and <tt>glx.h</tt>. Making sure that all extension definitions are 588 properly protected helps to this end, as well as being good 589 programming practice. </p> 590 591<p> <a name="issue4.8"></a> 592 <b>Section 4.8</b>: 593 <tt>GL_OGLBASE_VERSION</tt> is mostly provided so that apps can 594 determine whether to use traditional static linking of extensions, 595 or to dynamically query them. Unlike GL/GLX versioning, the ABI 596 version is not dynamically queryable at runtime. Historical 597 experience suggests that not providing the runtime query to begin 598 with is a bad decision. </p> 599 600<p> <a name="issue5.1"></a> 601 <b>Section 5.1</b>: 602 <tt>glext.h</tt> is an exception to the Linux-centric nature of this 603 document, since it is already being used on other platforms. </p> 604 605<p> <a name="issue5.2"></a> 606 <b>Section 5.2</b>: 607 Applications should <b>not</b> use the version number in 608 <tt>glext.h</tt> to test for presence or absence of specific 609 extension prototypes; this is extremely unportable and dangerous. 610 Always use the extension-specific symbols described in section 5.3. 611 </p> 612 613<p> The header version symbol was changed from 614 <tt>GL_GLEXT_VERSION_EXT</tt> to <tt>GL_GLEXT_VERSION</tt> for 615 consistency with the <tt>GLEXT</tt> namespace the ABI group has 616 started using. </p> 617 618<p> <a name="issue5.3"></a> 619 <b>Section 5.3</b>: 620 Other structures for the extension prototypes have been suggested, 621 such as having separate header files for each extension. Having both 622 structures may be preferable, but it requires more work. </p> 623 624<p> <a name="issue5.4"></a> 625 <b>Section 5.4</b>: 626 It's important to be able to suppress automatic inclusion of 627 <tt>glext.h</tt> and <tt>glxext.h</tt> in order to support 628 compilation of legacy code not written to be ABI-aware (e.g. 629 assuming that extensions can be statically linked). </p> 630 631<p> <a name="log"></a></p> 632<h6>7. Change Log</h6> 633 634<ul> 635<li> 10/9/2006 - updated registry links to the new location on 636 opengl.org and cleaned up other dangling wording due to the move 637 from oss.sgi.com. 638<li> 6/20/2000 (version 1.0) - Linux ABI approved on the oglbase-discuss 639 mailing list. Corrected Windows function-pointer typedef convention 640 in section 5.3 by appending <tt>PROC</tt>, to match what glext.h 641 already does. </li> 642<li> 5/29/2000 (version 0.9.8) - <tt>glxext.h</tt> added to section 4. 643 Resolution reached on the structure of <tt>glext.h</tt> and 644 <tt>glxext.h</tt>, and how they are included from <tt>gl.h</tt> and 645 <tt>glx.h</tt>. In particular, <tt>GL_OGLBASE_VERSION</tt> symbol 646 defined, default inclusion of extension headers from core headers 647 mandated, <tt>GL_GLEXT_PROTOTYPES</tt> may be specified in order to 648 get extension prototypes as well as function pointer typedefs. 649 Renamed <tt>GL_GLEXT_VERSION_EXT</tt> to <tt>GL_GLEXT_VERSION</tt>. 650 </li> 651<li> 4/9/2000 (version 0.9.7) - <tt>glext.h</tt> is now available 652 together with the ABI specification. </li> 653<li> 2/22/2000 (version 0.9.6) - Revised for public comment period. 654 Moved open issues to the new appendix. </li> 655<li> 2/8/2000 (version 0.9.5) - Removed ellipses from prototype in 656 section 3.6, and simplified the lists of SGI supported extensions 657 into one file. Mandated threadsafety in section 3.7. Moved 658 glXGetProcAddressARB prototype from gl.h to glx.h in section 4.4, 659 since the function itself was moved from gl to glX during 660 standardization. Restructured the page to fit into the ogl-sample 661 site on oss.sgi.com, next to the extension registry. Pointed to the 662 updated extension registry on oss.sgi.com in several places. </li> 663<li> 12/9/99 (version 0.9.4) - Added Intergraph extension list in 664 section 3.6. </li> 665<li> 12/6/99 (version 0.9.3) - Added Compaq and 3Dlabs extension 666 lists in section 3.6. </li> 667<li> 11/23/99 (version 0.9.2) - Refined discussion of 668 glXGetProcAddressARB to specify that any GL or GLX function can be 669 queried. </li> 670<li> 11/23/99 (version 0.9.1) - Summing up lots of email discussion. 671 Expanded participant list in section 1.4. Pinned down library 672 naming scheme in section 3.1. Changed to require statically 673 exporting all GL 1.2 / GLX 1.3 / GLU 1.3 / ARB extension entry 674 points in section 3.4. Changed GetProcAddress from EXT to ARB and 675 from gl to glX(in anticipation of ARB approval) in section 3.5. 676 Does <b>not</b> require a context parameter. Require Windows naming 677 convention for <tt>glext.h</tt> function prototypes in section 5.3. 678 Added a link to the list archives in section 6. </li> 679<li> 9/16/1999 - Added Mesa, Sun, and Xi Graphics extension lists in 680 section 3.6. Added section 3.8 on transitive library dependencies 681 of the GL libraries. </li> 682<li> 9/10/1999 - Added initial list of GL/GLX/GLU extensions 683 for existing platforms in section 3.6.<br> 684 Specified text/link colors as well as background color. </li> 685<li> 9/7/1999 - Initial version. </li> 686</ul> 687 688<?php include_once("../../../assets/static_pages/khr_page_bottom.php"); ?> 689</body> 690</html> 691