15bd8deadSopenharmony_ci<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> 25bd8deadSopenharmony_ci<html> 35bd8deadSopenharmony_ci<head> 45bd8deadSopenharmony_ci 55bd8deadSopenharmony_ci<title>OpenML ABI/DDI (DRAFT July 19, 2001)</title> 65bd8deadSopenharmony_ci 75bd8deadSopenharmony_ci<meta name="description" content="OpenML ABI/DDI standards"> 85bd8deadSopenharmony_ci<meta name="keywords" content="OpenML, OpenGL, ABI, Linux"> 95bd8deadSopenharmony_ci<meta name="owner" content="Jon Leech"> 105bd8deadSopenharmony_ci 115bd8deadSopenharmony_ci<center> 125bd8deadSopenharmony_ci<h2> OpenML® Application Binary Interface (ABI) and Device Driver 135bd8deadSopenharmony_ci Interface (DDI) Standards </h2> 145bd8deadSopenharmony_ci 155bd8deadSopenharmony_ci<p>Version 0.2<br> 165bd8deadSopenharmony_ci July 19, 2001<br> 175bd8deadSopenharmony_ci Editor: Jon Leech, SGI 185bd8deadSopenharmony_ci</center> 195bd8deadSopenharmony_ci 205bd8deadSopenharmony_ci<p><hr></p> 215bd8deadSopenharmony_ci 225bd8deadSopenharmony_ci<h2> Index </h2> 235bd8deadSopenharmony_ci 245bd8deadSopenharmony_ci <ul> 255bd8deadSopenharmony_ci <li><a href="#1">1. Overview and Goals </a> 265bd8deadSopenharmony_ci <li><a href="#2">2. OpenML Component APIs and Versions</a> 275bd8deadSopenharmony_ci <li><a href="#3">3. Calling Conventions</a> 285bd8deadSopenharmony_ci <li><a href="#4">4. Libraries</a> 295bd8deadSopenharmony_ci <li><a href="#5">5. Header Files</a> 305bd8deadSopenharmony_ci <li><a href="#6">6. Extension Mechanism and Extension Headers</a> 315bd8deadSopenharmony_ci <li><a href="#7">7. Device Driver Interfaces</a> 325bd8deadSopenharmony_ci <li><a href="#app">Appendix: Open Issues</a> 335bd8deadSopenharmony_ci <li><a href="#log">Change Log</a> 345bd8deadSopenharmony_ci </ul> 355bd8deadSopenharmony_ci 365bd8deadSopenharmony_ci<a name="1"> 375bd8deadSopenharmony_ci<h2> 1. Overview and Goals </h2> 385bd8deadSopenharmony_ci 395bd8deadSopenharmony_ci<p> 1.1. This document is intended to solve three related problems. 405bd8deadSopenharmony_ci First, defining the ABIs and runtime environment for applications 415bd8deadSopenharmony_ci using OpenML. This will enable applications using the OpenML APIs 425bd8deadSopenharmony_ci for rendering to run on a variety of underlying implementations 435bd8deadSopenharmony_ci transparently. 445bd8deadSopenharmony_ci 455bd8deadSopenharmony_ci<p> Second, defining the Software Development Kit (SDK) (for developing 465bd8deadSopenharmony_ci apps using OpenGL. This includes header file locations, conventions 475bd8deadSopenharmony_ci for use of extensions, etc. 485bd8deadSopenharmony_ci 495bd8deadSopenharmony_ci<p> Finally, defining the Device Driver Interface (DDI) for appropriate 505bd8deadSopenharmony_ci portions of OpenML. 515bd8deadSopenharmony_ci 525bd8deadSopenharmony_ci<p> These standards target multiple platforms. For Linux and Microsoft 535bd8deadSopenharmony_ci Windows, where multiple vendors will supply OpenML implementations, 545bd8deadSopenharmony_ci the standards are <b>proscriptive</b>; all conformant OpenML 555bd8deadSopenharmony_ci implementations must satisfy the ABI, SDK, and DDI requirements. For 565bd8deadSopenharmony_ci other platforms (at this time, vendor-specific Unix platforms such 575bd8deadSopenharmony_ci as IRIX or Solaris), only some parts of the standards are required, 585bd8deadSopenharmony_ci while others are <b>recommended</b>, for maximal portability between 595bd8deadSopenharmony_ci platforms. 605bd8deadSopenharmony_ci 615bd8deadSopenharmony_ci<p> It may eventually be appropriate to share these standards with 625bd8deadSopenharmony_ci broader standards bodies such as the 635bd8deadSopenharmony_ci <a href="http://www.freestandards.org">Free Standards Group</a> on 645bd8deadSopenharmony_ci Linux. 655bd8deadSopenharmony_ci 665bd8deadSopenharmony_ci<p> 1.2. There are many open issues in the initial draft; this is 675bd8deadSopenharmony_ci intended for discussion and extensive modification. Open issues are 685bd8deadSopenharmony_ci summarized in the <a href="#app">appendix</a>. Some decisions are 695bd8deadSopenharmony_ci largely arbitrary (filenames and file locations, for example), and 705bd8deadSopenharmony_ci in those cases we have been guided by existing practice where 715bd8deadSopenharmony_ci possible. 725bd8deadSopenharmony_ci 735bd8deadSopenharmony_ci<p> 1.3. This document is intended to become part of the OpenML 745bd8deadSopenharmony_ci Specification on its approval, and is a joint work of the 755bd8deadSopenharmony_ci <a href="http://www.khronos.org">Khronos SIG</a>.</p> 765bd8deadSopenharmony_ci 775bd8deadSopenharmony_ci<a name="2"> 785bd8deadSopenharmony_ci<h2> 2. OpenML Component APIs and Versions </h2> 795bd8deadSopenharmony_ci 805bd8deadSopenharmony_ci<h3> 2.1. Component APIs </h3> 815bd8deadSopenharmony_ci 825bd8deadSopenharmony_ci<p> OpenML requires implementations of several separate APIs: <b>ML</b>, 835bd8deadSopenharmony_ci <b>MLdc</b>, and <b>OpenGL</b>. For the most part, the ABIs, SDKs, 845bd8deadSopenharmony_ci and DDIs required for each of these APIs are not related, and are 855bd8deadSopenharmony_ci described separately. Interactions are documented where needed. 865bd8deadSopenharmony_ci 875bd8deadSopenharmony_ci<h3> 2.2. ML </h3> 885bd8deadSopenharmony_ci 895bd8deadSopenharmony_ci<p> ML is the <i>Media Library</i> component of OpenML. It is a 905bd8deadSopenharmony_ci low-level API for accessing video and audio hardware. 915bd8deadSopenharmony_ci 925bd8deadSopenharmony_ci<h3> 2.3. MLdc </h3> 935bd8deadSopenharmony_ci 945bd8deadSopenharmony_ci<p> MLdc is the <i>Display Control</i> component of OpenML. It manages 955bd8deadSopenharmony_ci multiple video <i>channels</i>, including aspects such as video 965bd8deadSopenharmony_ci formats, timing, gamma tables, etc. 975bd8deadSopenharmony_ci 985bd8deadSopenharmony_ci<h3> 2.4. OpenGL </h3> 995bd8deadSopenharmony_ci 1005bd8deadSopenharmony_ci<p> OpenGL is the <i>Graphics</i> component of OpenML. It is a low-level 1015bd8deadSopenharmony_ci API for performing 3D rendering. OpenGL is standardized separately 1025bd8deadSopenharmony_ci from OpenML by the <a href="http://www.opengl.org/">OpenGL 1035bd8deadSopenharmony_ci Architecture Review Board</a>; OpenML simply requires a specific 1045bd8deadSopenharmony_ci version of OpenGL with a small number of added API extensions for 1055bd8deadSopenharmony_ci managing video data. 1065bd8deadSopenharmony_ci 1075bd8deadSopenharmony_ci<p> Because OpenGL is a pre-existing API with shipping implementations, 1085bd8deadSopenharmony_ci this document mostly refers to other standards (such as the <a 1095bd8deadSopenharmony_ci href="http://oss.sgi.com/projects/ogl-sample/ABI/">OpenGL ABI for 1105bd8deadSopenharmony_ci Linux</a>) when defining OpenGL-specific standards.</p> 1115bd8deadSopenharmony_ci 1125bd8deadSopenharmony_ci<h3> 2.5. Versions </h3> 1135bd8deadSopenharmony_ci 1145bd8deadSopenharmony_ci<p> This document defines ABIs and DDIs for the OpenML 1.0 APIs. </p> 1155bd8deadSopenharmony_ci 1165bd8deadSopenharmony_ci<a name="3"> 1175bd8deadSopenharmony_ci<h2> 3. Calling Conventions </h2> 1185bd8deadSopenharmony_ci 1195bd8deadSopenharmony_ci<h3> 3.1. ML Calling Conventions </h3> 1205bd8deadSopenharmony_ci 1215bd8deadSopenharmony_ci<p> <b>OPEN</b> - need to define ML datatype required sizes, Windows / Linux 1225bd8deadSopenharmony_ci / etc. conventions. 1235bd8deadSopenharmony_ci 1245bd8deadSopenharmony_ci<h3> 3.2. MLdc Calling Conventions </h3> 1255bd8deadSopenharmony_ci 1265bd8deadSopenharmony_ci<p> <b>OPEN</b> - need to define MLdc datatype required sizes, Windows / 1275bd8deadSopenharmony_ci Linux / etc. conventions. 1285bd8deadSopenharmony_ci 1295bd8deadSopenharmony_ci<h3> 3.3. OpenGL Calling Conventions </h3> 1305bd8deadSopenharmony_ci 1315bd8deadSopenharmony_ci<p> 3.3.1. <b>Linux</b> - the OpenGL implementation must follow the 1325bd8deadSopenharmony_ci calling and datatype conventions defined by the <a 1335bd8deadSopenharmony_ci href="http://oss.sgi.com/projects/ogl-sample/ABI/">OpenGL ABI for 1345bd8deadSopenharmony_ci Linux</a>. 1355bd8deadSopenharmony_ci 1365bd8deadSopenharmony_ci<p> 3.3.2. <b>Windows</b> - the OpenGL implementation must follow the 1375bd8deadSopenharmony_ci calling and datatype conventions established <i>de facto</i> by 1385bd8deadSopenharmony_ci Microsoft's <tt>OPENGL32.DLL</tt> and header files. 1395bd8deadSopenharmony_ci 1405bd8deadSopenharmony_ci<p> 3.3.3. <b>Other Platforms</b> - calling conventions are 1415bd8deadSopenharmony_ci platform-dependent. Datatype conventions are platform dependent so 1425bd8deadSopenharmony_ci long as they satisfy the minimum size requirements of the OpenGL 1435bd8deadSopenharmony_ci Specification. 1445bd8deadSopenharmony_ci 1455bd8deadSopenharmony_ci<p> <b>Issues:</b> Do we need to address C++ linking issues? Need more 1465bd8deadSopenharmony_ci detail on calling conventions for Linux?</p> 1475bd8deadSopenharmony_ci 1485bd8deadSopenharmony_ci<a name="4"> 1495bd8deadSopenharmony_ci<h2> 4. Libraries </h2> 1505bd8deadSopenharmony_ci 1515bd8deadSopenharmony_ci<h3> 4.1. ML Library </h3> 1525bd8deadSopenharmony_ci 1535bd8deadSopenharmony_ci<p> There is a single user-level ML link library. It includes ML entry 1545bd8deadSopenharmony_ci points, and in general makes use of underlying hardware drivers for 1555bd8deadSopenharmony_ci hardware device access. Hardware drivers may be incorporated into 1565bd8deadSopenharmony_ci the link library, but in general they are loaded by the link library 1575bd8deadSopenharmony_ci at runtime, and accessed through a <a href="#DDIsection">Device 1585bd8deadSopenharmony_ci Driver Interface</a> defined below. 1595bd8deadSopenharmony_ci 1605bd8deadSopenharmony_ci<p> 4.1.1 <b>Linux</b> - the link library has two names: that used on 1615bd8deadSopenharmony_ci the ld command line, and the <tt>DT_SONAME</tt> within that library 1625bd8deadSopenharmony_ci (specified by the <i>-soname</i> switch when linking the library), 1635bd8deadSopenharmony_ci defining where it's looked up at runtime. Both forms must exist so 1645bd8deadSopenharmony_ci that both linking and running will operate properly. 1655bd8deadSopenharmony_ci 1665bd8deadSopenharmony_ci<p> The <tt>DT_SONAME</tt> includes the ML major version number, and is 1675bd8deadSopenharmony_ci <tt>libML.so.1</tt>. The <i>link library name</i> is 1685bd8deadSopenharmony_ci <tt>libML.so</tt>. <tt>libML.so</tt> must be implemented as a 1695bd8deadSopenharmony_ci symbolic link to <tt>libML.so.1</tt>. This allows future major 1705bd8deadSopenharmony_ci revisions of ML to be implemented transparently to applications by 1715bd8deadSopenharmony_ci simply changing the link; new applications will link with the new 1725bd8deadSopenharmony_ci runtime library, while old, compiled applications will continue to 1735bd8deadSopenharmony_ci use the old runtime. 1745bd8deadSopenharmony_ci 1755bd8deadSopenharmony_ci<p> <b>Issues:</b> do we need static link libraries? 1765bd8deadSopenharmony_ci 1775bd8deadSopenharmony_ci<p> Both ML libraries must be located in <tt>/usr/lib</tt>. 1785bd8deadSopenharmony_ci 1795bd8deadSopenharmony_ci<p> 4.1.2. <b>Windows</b> - the link library is named <tt>ML32.DLL</tt>. 1805bd8deadSopenharmony_ci It must be located in <tt>\System\???</tt> 1815bd8deadSopenharmony_ci 1825bd8deadSopenharmony_ci<p> <b>Issues:</b> What the heck are the Windows system library 1835bd8deadSopenharmony_ci conventions, anyway? And will we run into the horrid Windows XP 1845bd8deadSopenharmony_ci "driver signing" mess by mandating the library live in 1855bd8deadSopenharmony_ci <tt>\System</tt>? 1865bd8deadSopenharmony_ci 1875bd8deadSopenharmony_ci<p> 4.1.3. <b>Other Platforms</b> - the base name of the library should 1885bd8deadSopenharmony_ci be <tt>libML</tt>, so that crossplatform Unix build systems can 1895bd8deadSopenharmony_ci always use "-lML" on their link lines. The ML major version number 1905bd8deadSopenharmony_ci (1) should be incorporated into the link library name in appropriate 1915bd8deadSopenharmony_ci fashion. The library should be shared, and should use whatever the 1925bd8deadSopenharmony_ci platform's library versioning mechanism is to cause compiled 1935bd8deadSopenharmony_ci applications to resolve to resolve to the correct version of 1945bd8deadSopenharmony_ci <tt>libML</tt> (e.g. the one they were linked against), even if a 1955bd8deadSopenharmony_ci newer major version has become the default. 1965bd8deadSopenharmony_ci 1975bd8deadSopenharmony_ci<p> The ML library is typically located in <tt>/usr/lib</tt>, although 1985bd8deadSopenharmony_ci platform conventions may override this. The important point is that 1995bd8deadSopenharmony_ci there be a single, standard location for the link library on that 2005bd8deadSopenharmony_ci platform. 2015bd8deadSopenharmony_ci 2025bd8deadSopenharmony_ci<h3> 4.2. MLdc Library </h3> 2035bd8deadSopenharmony_ci 2045bd8deadSopenharmony_ci<p> There is a single user-level MLdc link library. It includes MLdc 2055bd8deadSopenharmony_ci entry points, and in general makes use of underlying hardware 2065bd8deadSopenharmony_ci drivers for hardware device access. Hardware drivers may be 2075bd8deadSopenharmony_ci incorporated into the link library, but in general they are loaded 2085bd8deadSopenharmony_ci by the link library or the window system at runtime, and accessed 2095bd8deadSopenharmony_ci through a <a href="#DDIsection">Device Driver Interface</a> defined 2105bd8deadSopenharmony_ci below. 2115bd8deadSopenharmony_ci 2125bd8deadSopenharmony_ci<p> 4.2.1 <b>Linux</b> - the link library has two names: that used on 2135bd8deadSopenharmony_ci the ld command line, and the <tt>DT_SONAME</tt> within that library 2145bd8deadSopenharmony_ci (specified by the <i>-soname</i> switch when linking the library), 2155bd8deadSopenharmony_ci defining where it's looked up at runtime. Both forms must exist so 2165bd8deadSopenharmony_ci that both linking and running will operate properly. 2175bd8deadSopenharmony_ci 2185bd8deadSopenharmony_ci<p> The <tt>DT_SONAME</tt> includes the MLdc major version number, and 2195bd8deadSopenharmony_ci is <tt>libMLdc.so.1</tt>. The <i>link library name</i> is 2205bd8deadSopenharmony_ci <tt>libMLdc.so</tt>. <tt>libMLdc.so</tt> must be implemented as a 2215bd8deadSopenharmony_ci symbolic link to <tt>libMLdc.so.1</tt>. This allows future major 2225bd8deadSopenharmony_ci revisions of MLdc to be implemented transparently to applications by 2235bd8deadSopenharmony_ci simply changing the link; new applications will link with the new 2245bd8deadSopenharmony_ci runtime library, while old, compiled applications will continue to 2255bd8deadSopenharmony_ci use the old runtime. 2265bd8deadSopenharmony_ci 2275bd8deadSopenharmony_ci<p> <b>Issues:</b> do we need static link libraries? 2285bd8deadSopenharmony_ci 2295bd8deadSopenharmony_ci<p> Both MLdc libraries must be located in <tt>/usr/lib</tt>. 2305bd8deadSopenharmony_ci 2315bd8deadSopenharmony_ci<p> 4.2.2. <b>Windows</b> - the link library is named 2325bd8deadSopenharmony_ci <tt>MLDC32.DLL</tt>. It must be located in <tt>\System\???</tt> 2335bd8deadSopenharmony_ci 2345bd8deadSopenharmony_ci<p> <b>Issues:</b> As for <tt>ML32.DLL</tt> - decide where 2355bd8deadSopenharmony_ci the library lives. 2365bd8deadSopenharmony_ci "driver signing" mess by mandating the library live in 2375bd8deadSopenharmony_ci <tt>\System</tt>? 2385bd8deadSopenharmony_ci 2395bd8deadSopenharmony_ci<p> 4.2.3. <b>Other Platforms</b> - the base name of the library should 2405bd8deadSopenharmony_ci be <tt>libMLdc</tt>, so that crossplatform Unix build systems can 2415bd8deadSopenharmony_ci always use "-lMLdc" on their link lines. The MLdc major version 2425bd8deadSopenharmony_ci number (1) should be incorporated into the link library name in 2435bd8deadSopenharmony_ci appropriate fashion. The library should be shared, and should use 2445bd8deadSopenharmony_ci whatever the platform's library versioning mechanism is to cause 2455bd8deadSopenharmony_ci compiled applications to resolve to resolve to the correct version 2465bd8deadSopenharmony_ci of <tt>libMLdc</tt> (e.g. the one they were linked against), even if 2475bd8deadSopenharmony_ci a newer major version has become the default. 2485bd8deadSopenharmony_ci 2495bd8deadSopenharmony_ci<p> The MLdc library is typically located in <tt>/usr/lib</tt>, although 2505bd8deadSopenharmony_ci platform conventions may override this. The important point is that 2515bd8deadSopenharmony_ci there be a single, standard location for the link library on that 2525bd8deadSopenharmony_ci platform. 2535bd8deadSopenharmony_ci 2545bd8deadSopenharmony_ci<h3> 4.3. OpenGL Library </h3> 2555bd8deadSopenharmony_ci 2565bd8deadSopenharmony_ci<p> There is a single user-level OpenGL link library. It includes OpenGL 2575bd8deadSopenharmony_ci entry points, and in general makes use of underlying hardware 2585bd8deadSopenharmony_ci drivers for hardware device access. Hardware drivers may be 2595bd8deadSopenharmony_ci incorporated into the link library, but in general they are loaded 2605bd8deadSopenharmony_ci by the link library or the window system at runtime, and accessed 2615bd8deadSopenharmony_ci through a <a href="#DDIsection">Device Driver Interface</a> defined 2625bd8deadSopenharmony_ci below. 2635bd8deadSopenharmony_ci 2645bd8deadSopenharmony_ci<p> 4.3.1 <b>Linux</b> - the OpenGL library naming, location, and 2655bd8deadSopenharmony_ci versioning conventions are as defined by the <a 2665bd8deadSopenharmony_ci href="http://oss.sgi.com/projects/ogl-sample/ABI/">OpenGL ABI for 2675bd8deadSopenharmony_ci Linux</a>. 2685bd8deadSopenharmony_ci 2695bd8deadSopenharmony_ci<p> 4.3.2. <b>Windows</b> - the OpenGL library is shipped by Microsoft 2705bd8deadSopenharmony_ci in <tt>\System\OPENGL32.DLL</tt>. 2715bd8deadSopenharmony_ci 2725bd8deadSopenharmony_ci<p> 4.3.3. <b>Other Platforms</b> - follow existing conventions on those 2735bd8deadSopenharmony_ci platforms (typically the OpenGL library is linked via "-lGL"). New 2745bd8deadSopenharmony_ci platforms without existing conventions should follow the Linux 2755bd8deadSopenharmony_ci conventions insofar as possible. 2765bd8deadSopenharmony_ci 2775bd8deadSopenharmony_ci<h3> 4.4. Additional Issues </h3> 2785bd8deadSopenharmony_ci 2795bd8deadSopenharmony_ci<p> <ul> 2805bd8deadSopenharmony_ci <li> C++ runtime issues on Linux? 2815bd8deadSopenharmony_ci <li> Entry points guaranteed in each library. 2825bd8deadSopenharmony_ci <li> Thread safety. 2835bd8deadSopenharmony_ci <li> Transitive linking of required libraries. 2845bd8deadSopenharmony_ci </ul> 2855bd8deadSopenharmony_ci 2865bd8deadSopenharmony_ci<a name="5"> 2875bd8deadSopenharmony_ci<h2> 5. Header Files </h2> 2885bd8deadSopenharmony_ci 2895bd8deadSopenharmony_ci<h3> 5.1. ML Header Files </h3> 2905bd8deadSopenharmony_ci 2915bd8deadSopenharmony_ci<p> 5.1.1. The following header files are required for ML: 2925bd8deadSopenharmony_ci 2935bd8deadSopenharmony_ci <ul> 2945bd8deadSopenharmony_ci <li> <b>TBD</b> 2955bd8deadSopenharmony_ci </ul> 2965bd8deadSopenharmony_ci 2975bd8deadSopenharmony_ci<p> Language bindings supported - <b>TBD</b> (C and C++?) 2985bd8deadSopenharmony_ci 2995bd8deadSopenharmony_ci<p> Header locations - <b>TBD</b> (presumably /usr/include/ML on 3005bd8deadSopenharmony_ci Linux/Unix) 3015bd8deadSopenharmony_ci 3025bd8deadSopenharmony_ci<p> Header contents - <b>TBD</b> (ML 1.0) 3035bd8deadSopenharmony_ci 3045bd8deadSopenharmony_ci<h3> 5.2. MLdc Header Files</h3> 3055bd8deadSopenharmony_ci 3065bd8deadSopenharmony_ci<p> 5.2.1. The following header files are required for MLdc: 3075bd8deadSopenharmony_ci 3085bd8deadSopenharmony_ci <ul> 3095bd8deadSopenharmony_ci <li> <b>TBD</b> 3105bd8deadSopenharmony_ci </ul> 3115bd8deadSopenharmony_ci 3125bd8deadSopenharmony_ci<p> Language bindings supported - <b>TBD</b> (C and C++?) 3135bd8deadSopenharmony_ci 3145bd8deadSopenharmony_ci<p> Header locations - <b>TBD</b> (/usr/include/ML? check w/Cary) 3155bd8deadSopenharmony_ci 3165bd8deadSopenharmony_ci<p> Header contents - <b>TBD</b> (MLdc 1.0) 3175bd8deadSopenharmony_ci 3185bd8deadSopenharmony_ci<h3> 5.3. OpenGL Header Files </h3> 3195bd8deadSopenharmony_ci 3205bd8deadSopenharmony_ci<p> 5.3.1 <b>Linux</b> - the OpenGL header file requirements are as 3215bd8deadSopenharmony_ci defined by the <a 3225bd8deadSopenharmony_ci href="http://oss.sgi.com/projects/ogl-sample/ABI/">OpenGL ABI for 3235bd8deadSopenharmony_ci Linux</a>. In addition, <tt>glext.h</tt> and <tt>glxext.h</tt> must 3245bd8deadSopenharmony_ci define interfaces for the OpenGL and GLX extensions, respectively, 3255bd8deadSopenharmony_ci required by OpenML 1.0. 3265bd8deadSopenharmony_ci 3275bd8deadSopenharmony_ci<p> 5.3.2. <b>Windows</b> - the following header files 3285bd8deadSopenharmony_ci are required: 3295bd8deadSopenharmony_ci 3305bd8deadSopenharmony_ci <ul> 3315bd8deadSopenharmony_ci <li> <tt><GL/gl.h></tt> - OpenGL 3325bd8deadSopenharmony_ci <li> <tt><GL/wgl.h></tt> - WGL 3335bd8deadSopenharmony_ci <li> <tt><GL/glu.h></tt> - GLU 3345bd8deadSopenharmony_ci <li> <tt><GL/glext.h></tt> - OpenGL Extensions 3355bd8deadSopenharmony_ci <li> <tt><GL/wglext.h></tt> - WGL Extensions 3365bd8deadSopenharmony_ci </ul> 3375bd8deadSopenharmony_ci 3385bd8deadSopenharmony_ci<p> gl.h, glu.h, and wgl.h are typically supplied by Microsoft, 3395bd8deadSopenharmony_ci while <tt>glext.h</tt> and <tt>wglext.h</tt> should be obtained from 3405bd8deadSopenharmony_ci the OpenGL extension registry. <tt>glext.h</tt> and 3415bd8deadSopenharmony_ci <tt>wglext.h</tt> must define interfaces for the OpenGL and WGL 3425bd8deadSopenharmony_ci extensions, respectively, required by OpenML 1.0. 3435bd8deadSopenharmony_ci 3445bd8deadSopenharmony_ci<p> Header locations - <b>TBD</b> (check existing practice for 3455bd8deadSopenharmony_ci MS-supplied headers; define a location for others). 3465bd8deadSopenharmony_ci 3475bd8deadSopenharmony_ci<p> 5.3.3. <b>Other Platforms</b> - follow existing conventions on those 3485bd8deadSopenharmony_ci platforms (typically header files are placed in 3495bd8deadSopenharmony_ci <tt>/usr/include/GL</tt>). However, all implementations must provide 3505bd8deadSopenharmony_ci <tt>glext.h</tt> and, for implementations on the X Window System and 3515bd8deadSopenharmony_ci GLX, <tt>glxext.h</tt>, and all OpenML 1.0 extensions must be 3525bd8deadSopenharmony_ci defined in those headers. 3535bd8deadSopenharmony_ci 3545bd8deadSopenharmony_ci<p> New platforms without existing conventions should follow the Linux 3555bd8deadSopenharmony_ci conventions insofar as possible. 3565bd8deadSopenharmony_ci 3575bd8deadSopenharmony_ci<h3> 5.4. General Issues </h3> 3585bd8deadSopenharmony_ci 3595bd8deadSopenharmony_ci<p> Required header files must not pull in internal headers or headers 3605bd8deadSopenharmony_ci from other packages where that would cause unexpected namespace 3615bd8deadSopenharmony_ci pollution. They must be protected against multiple inclusion and 3625bd8deadSopenharmony_ci should not themselves include any headers that are not so protected. 3635bd8deadSopenharmony_ci 3645bd8deadSopenharmony_ci<p> Vendor-specific shortcuts, such as macros for higher performance GL 3655bd8deadSopenharmony_ci entry points, are intrinsically unportable. These should <b>not</b> 3665bd8deadSopenharmony_ci be present in any required header files, but instead in a 3675bd8deadSopenharmony_ci vendor-specific header file that requires explicit effort by 3685bd8deadSopenharmony_ci developers to access, such as defining a vendor-specific 3695bd8deadSopenharmony_ci preprocessor symbol or including a vendor-specific header file.</p> 3705bd8deadSopenharmony_ci 3715bd8deadSopenharmony_ci<!-- <font face="Arial" size="2">yadda yadda</font> --> 3725bd8deadSopenharmony_ci 3735bd8deadSopenharmony_ci<a name="6"> 3745bd8deadSopenharmony_ci<h2> 6. Extension Mechanism and Extension Headers </h2> 3755bd8deadSopenharmony_ci 3765bd8deadSopenharmony_ci<h3> 6.1. General Requirements </h3> 3775bd8deadSopenharmony_ci 3785bd8deadSopenharmony_ci<p> The ML, MLdc, and OpenGL APIs may be extended by individual vendors 3795bd8deadSopenharmony_ci or groups of vendors to provide functionality specific to some 3805bd8deadSopenharmony_ci implementations. Such extensions take the form of new entry points 3815bd8deadSopenharmony_ci and/or new parameters to existing functions. 3825bd8deadSopenharmony_ci 3835bd8deadSopenharmony_ci<p> In general each API will be exposed to applications as a single link 3845bd8deadSopenharmony_ci library, with the library dispatching functions to hardware-specific 3855bd8deadSopenharmony_ci drivers as appropriate. If vendors providing extensions each 3865bd8deadSopenharmony_ci provided a modified link library, binary applications could not 3875bd8deadSopenharmony_ci reliably be moved from system to system, because incompatible 3885bd8deadSopenharmony_ci interfaces would be provided depending on the source of the library. 3895bd8deadSopenharmony_ci 3905bd8deadSopenharmony_ci<p> To deal with this, each API provides an <i>extension mechanism</i> 3915bd8deadSopenharmony_ci which lets applications obtain new entry points (pointers to 3925bd8deadSopenharmony_ci functions within driver modules) dynamically at runtime. 3935bd8deadSopenharmony_ci 3945bd8deadSopenharmony_ci<p> Similarly, if each vendor provided modified header files adding 3955bd8deadSopenharmony_ci their extensions, it would be difficult to build applications 3965bd8deadSopenharmony_ci consistently in different environments. To deal with this, each API 3975bd8deadSopenharmony_ci defines the structure of a <i>extension header</i> which defines 3985bd8deadSopenharmony_ci interfaces for all known extensions and can be maintained at a 3995bd8deadSopenharmony_ci central source. 4005bd8deadSopenharmony_ci 4015bd8deadSopenharmony_ci<h3> 6.2. ML Extensions </h3> 4025bd8deadSopenharmony_ci 4035bd8deadSopenharmony_ci<p> 6.2.1. The ML extension mechanism and extension headers 4045bd8deadSopenharmony_ci are not defined yet; this will be done for OpenML 1.1. 4055bd8deadSopenharmony_ci 4065bd8deadSopenharmony_ci<h3> 6.3. MLdc Extensions </h3> 4075bd8deadSopenharmony_ci 4085bd8deadSopenharmony_ci<p> 6.3.1. <i>Need to insert MLdc extension mechanism</i>. 4095bd8deadSopenharmony_ci 4105bd8deadSopenharmony_ci<h3> 6.4. OpenGL Extensions </h3> 4115bd8deadSopenharmony_ci 4125bd8deadSopenharmony_ci<p> 6.4.1. <b>Linux</b> - The OpenGL ABI for Linux defines the required 4135bd8deadSopenharmony_ci extension functionality, including the <b>glXGetProcAddressARB</b> 4145bd8deadSopenharmony_ci function (provided by the <tt>GLX_ARB_get_proc_address</tt> 4155bd8deadSopenharmony_ci extension) used to query extension interfaces. The <tt>glext.h</tt> 4165bd8deadSopenharmony_ci and <tt>glxext.h</tt> headers from the OpenGL extension registry 4175bd8deadSopenharmony_ci define interfaces to known OpenGL and GLX extensions. 4185bd8deadSopenharmony_ci 4195bd8deadSopenharmony_ci<p> 6.4.2. <b>Windows</b> - WGL provides the <b>wglGetProcAddress</b> 4205bd8deadSopenharmony_ci function used to query extension interfaces (unlike the GLX 4215bd8deadSopenharmony_ci equivalent, returned function pointers are <i>context dependent</i>; 4225bd8deadSopenharmony_ci portable code must be aware of this difference). <tt>glext.h</tt> 4235bd8deadSopenharmony_ci (identical to the Linux version) and <tt>wglext.h</tt> headers from 4245bd8deadSopenharmony_ci the OpenGL extension registry define interfaces to known OpenGL and 4255bd8deadSopenharmony_ci WGL extensions. 4265bd8deadSopenharmony_ci 4275bd8deadSopenharmony_ci<p> 6.4.3. <b>Other Platforms</b> - Unix platforms should follow the 4285bd8deadSopenharmony_ci Linux conventions, providing the <tt>GLX_ARB_get_proc_address</tt> 4295bd8deadSopenharmony_ci extension as well as <tt>glext.h</tt> and <tt>glxext.h</tt>. Other 4305bd8deadSopenharmony_ci platforms should define an extension with similar functionality and 4315bd8deadSopenharmony_ci provide <tt>glext.h</tt>; a companion extension header for window 4325bd8deadSopenharmony_ci system interface extensions may also need to be provided. </p> 4335bd8deadSopenharmony_ci 4345bd8deadSopenharmony_ci<a name="7"> 4355bd8deadSopenharmony_ci<h2> 7. Device Driver Interfaces </h2> 4365bd8deadSopenharmony_ci 4375bd8deadSopenharmony_ci<p> <b>TBD</b> - waiting on dmSDK DDI. 4385bd8deadSopenharmony_ci 4395bd8deadSopenharmony_ci 4405bd8deadSopenharmony_ci<p><hr></p> 4415bd8deadSopenharmony_ci 4425bd8deadSopenharmony_ci<a name="app"> 4435bd8deadSopenharmony_ci<h2> Appendix: Open Issues </h2> 4445bd8deadSopenharmony_ci 4455bd8deadSopenharmony_ci<p> <b>TBD</b> 4465bd8deadSopenharmony_ci 4475bd8deadSopenharmony_ci<!-- <p><a name="issue2.1"> 4485bd8deadSopenharmony_ci <b>Section 2.1</b>: 4495bd8deadSopenharmony_ci Define GL datatypes for other supported Linux architectures - Alpha, 4505bd8deadSopenharmony_ci PowerPC, MIPS, etc. (in general these will be identical to the IA32 4515bd8deadSopenharmony_ci types). Note: we may want to suggest <tt>GLlong</tt> and 4525bd8deadSopenharmony_ci <tt>GLulong</tt> as 64-bit datatypes for future OpenGL revisions. 4535bd8deadSopenharmony_ci--> 4545bd8deadSopenharmony_ci 4555bd8deadSopenharmony_ci 4565bd8deadSopenharmony_ci<a name="log"> 4575bd8deadSopenharmony_ci<h2> Change Log </h2> 4585bd8deadSopenharmony_ci 4595bd8deadSopenharmony_ci<ul> 4605bd8deadSopenharmony_ci<li> 2001/07/19 - Added extension mechanism section. 4615bd8deadSopenharmony_ci<li> 2001/04/17 - Initial version. 4625bd8deadSopenharmony_ci</ul> 4635bd8deadSopenharmony_ci 4645bd8deadSopenharmony_ci</body> 4655bd8deadSopenharmony_ci</html> 466