15bd8deadSopenharmony_ci<html> 25bd8deadSopenharmony_ci 35bd8deadSopenharmony_ci<head> 45bd8deadSopenharmony_ci<title>OpenGL Enumerant Allocation Policies</title> 55bd8deadSopenharmony_ci</head> 65bd8deadSopenharmony_ci 75bd8deadSopenharmony_ci<body> 85bd8deadSopenharmony_ci<h1>OpenGL Enumerant Allocation Policies</h1> 95bd8deadSopenharmony_ci 105bd8deadSopenharmony_ci<p> If an OpenGL vendor defines a single-vendor OpenGL or GLX extension 115bd8deadSopenharmony_ci that requires one or more new enumerant values, then each of those 125bd8deadSopenharmony_ci values must be contained in a block of enumerant values that has 135bd8deadSopenharmony_ci been allocated by Khronos for the exclusive use of that vendor. 145bd8deadSopenharmony_ci Khronos maintains a registry of such allocations. To allocate 155bd8deadSopenharmony_ci enumerants, file a request against project 'registry' in the Khronos 165bd8deadSopenharmony_ci Bugzilla. If you are unable to access Bugzilla, you may submit a 175bd8deadSopenharmony_ci request via email to "registry 'at' khronos.org". However, 185bd8deadSopenharmony_ci response time to email requests is unpredictable. 195bd8deadSopenharmony_ci 205bd8deadSopenharmony_ci<p> OpenGL and OpenGL ES use enumerant values in the range [0,24575], as 215bd8deadSopenharmony_ci well as reusing some enumerant values in the range [32768,65535]. 225bd8deadSopenharmony_ci The latter values were initially assigned to extensions which later 235bd8deadSopenharmony_ci became part of the OpenGL core. Enumerant values are grouped into 245bd8deadSopenharmony_ci blocks of 16 values, and each block begins with a value that is a 255bd8deadSopenharmony_ci multiple of 16. Most blocks in the range [0,24575] are unused, and 265bd8deadSopenharmony_ci reserved for use with future versions of OpenGL. 275bd8deadSopenharmony_ci 285bd8deadSopenharmony_ci<p> Historically, enumerant values for some single-vendor extensions 295bd8deadSopenharmony_ci were allocated in blocks of 1000, beginning with the block 305bd8deadSopenharmony_ci [102000,102999] and progressing upward. Values in this range cannot 315bd8deadSopenharmony_ci be represented as 16-bit unsigned integers. This imposes a 325bd8deadSopenharmony_ci significant and unnecessary performance penalty on some 335bd8deadSopenharmony_ci implementations. Such blocks that have already been allocated to 345bd8deadSopenharmony_ci vendors will remain allocated unless and until the vendor 355bd8deadSopenharmony_ci voluntarily releases the entire block, but no further blocks in this 365bd8deadSopenharmony_ci range will be allocated. 375bd8deadSopenharmony_ci 385bd8deadSopenharmony_ci<h3>Allocating Enumerants</h3> 395bd8deadSopenharmony_ci 405bd8deadSopenharmony_ci<p> Enumerant values for single-vendor extensions will be allocated upon 415bd8deadSopenharmony_ci request in blocks of 16 values, beginning with the block 425bd8deadSopenharmony_ci [32768,32783] and progressing upward. There are a limited number of 435bd8deadSopenharmony_ci available blocks in the more desirable 16-bit range [32768,65535], 445bd8deadSopenharmony_ci so do not request enumerants until you actually require them to ship 455bd8deadSopenharmony_ci an extension, or request more than you need. 465bd8deadSopenharmony_ci 475bd8deadSopenharmony_ci 485bd8deadSopenharmony_ci<p> Vendors must adhere to the following guidelines for requesting and 495bd8deadSopenharmony_ci using enumerants: 505bd8deadSopenharmony_ci 515bd8deadSopenharmony_ci<ul> 525bd8deadSopenharmony_ci 535bd8deadSopenharmony_ci<li> No extension can be shipped using OpenGL or GLX enumerant values 545bd8deadSopenharmony_ci that have not been allocated by the Registrar. 555bd8deadSopenharmony_ci 565bd8deadSopenharmony_ci<li> The Registrar will allocate official enumerant values for an 575bd8deadSopenharmony_ci extension only when there is a commitment to release that extension. 585bd8deadSopenharmony_ci Prior to this point, development work on the extension should be 595bd8deadSopenharmony_ci done using temporarily assigned enumerant values. Enumerant values 605bd8deadSopenharmony_ci in the range [0x6000,0x7FFF] (e.g. [24576,32767] are reserved for 615bd8deadSopenharmony_ci temporary use, and will never be assigned to any shipping core or 625bd8deadSopenharmony_ci extension enumerant. 635bd8deadSopenharmony_ci 645bd8deadSopenharmony_ci<li> An extension specification, following the <a 655bd8deadSopenharmony_ci href="template.html">template</a>, must exist prior to releasing an 665bd8deadSopenharmony_ci extension. The specification will ideally include all fields from 675bd8deadSopenharmony_ci the template; if this is proving difficult due to lack of 685bd8deadSopenharmony_ci familiarity with the appropriate API Specification, please consult 695bd8deadSopenharmony_ci with other implementers on the corresponding Khronos Working Group 705bd8deadSopenharmony_ci mailing list. Vendors are strongly encouraged to submit this 715bd8deadSopenharmony_ci specification to the registry. 725bd8deadSopenharmony_ci 735bd8deadSopenharmony_ci<li> Minimize the number of unused enumerant values in an allocated 745bd8deadSopenharmony_ci block. 755bd8deadSopenharmony_ci 765bd8deadSopenharmony_ci<li> Do not request blocks solely to reserve enumerants against 775bd8deadSopenharmony_ci anticipated future use. If you are likely to need a large contiguous 785bd8deadSopenharmony_ci block of enumerants in the future, this should be discussed with the 795bd8deadSopenharmony_ci Registrar. 805bd8deadSopenharmony_ci 815bd8deadSopenharmony_ci<li> If a vendor determines that it does not need a block of enumerant 825bd8deadSopenharmony_ci values that has been previously allocated to that vendor, the vendor 835bd8deadSopenharmony_ci may voluntarily return the entire block for future reallocation. 845bd8deadSopenharmony_ci 855bd8deadSopenharmony_ci<li> If an extension is promoted from single-vendor to multi-vendor 865bd8deadSopenharmony_ci <tt>EXT</tt> or <tt>ARB</tt> status, the following rule applies: for 875bd8deadSopenharmony_ci each enumerant that is present in both the single-vendor version and 885bd8deadSopenharmony_ci the multi-vendor version, a new multi-vendor extension enumerant 895bd8deadSopenharmony_ci will be defined with the same value as the single-vendor extension 905bd8deadSopenharmony_ci enumerant. The name of the new enumerant will be the name of the 915bd8deadSopenharmony_ci extension enumerant with the suffix <tt>EXT</tt> or <tt>ARB</tt> 925bd8deadSopenharmony_ci replacing the vendor-specific suffix. 935bd8deadSopenharmony_ci 945bd8deadSopenharmony_ci <p> Here, <i>promoted</i> is taken to mean that use of the 955bd8deadSopenharmony_ci single-vendor and multi-vendor enumerants is semantically 965bd8deadSopenharmony_ci equivalent, e.g. the effects of such use on GL and framebuffer state 975bd8deadSopenharmony_ci are identical. If this is not true, new values should be assigned to 985bd8deadSopenharmony_ci the multi-vendor enumerants. The intent is that it should be 995bd8deadSopenharmony_ci possible for the single-vendor and multi-vendor versions of the 1005bd8deadSopenharmony_ci extension to coexist in a single implementation. 1015bd8deadSopenharmony_ci 1025bd8deadSopenharmony_ci<li> If an extension becomes part of a new version of OpenGL, 1035bd8deadSopenharmony_ci the following rule applies: for each enumerant that is present in 1045bd8deadSopenharmony_ci both the extension and the new version of OpenGL, the ARB will 1055bd8deadSopenharmony_ci choose one of the following two options: 1065bd8deadSopenharmony_ci 1075bd8deadSopenharmony_ci <ul> 1085bd8deadSopenharmony_ci <li> Define a new OpenGL enumerant with the same value as the 1095bd8deadSopenharmony_ci extension enumerant. The name of the new enumerant will be the 1105bd8deadSopenharmony_ci name of the extension enumerant with the extension suffix 1115bd8deadSopenharmony_ci deleted. 1125bd8deadSopenharmony_ci 1135bd8deadSopenharmony_ci <li> Define a new OpenGL enumerant with a previously unused value in 1145bd8deadSopenharmony_ci the range [0,32767]. The name of the new enumerant will be the 1155bd8deadSopenharmony_ci name of the extension enumerant with the extension suffix 1165bd8deadSopenharmony_ci deleted. 1175bd8deadSopenharmony_ci </ul> 1185bd8deadSopenharmony_ci 1195bd8deadSopenharmony_ci<li> If a group of vendors introduces an extension, one of the vendors 1205bd8deadSopenharmony_ci in the group must be designated as the "lead vendor" for that 1215bd8deadSopenharmony_ci extension. The lead vendor will then allocate enumerant values for 1225bd8deadSopenharmony_ci the extension in the same way that it would allocate enumerant 1235bd8deadSopenharmony_ci values for a single-vendor extension. 1245bd8deadSopenharmony_ci</ul> 1255bd8deadSopenharmony_ci 1265bd8deadSopenharmony_ci<p> If at some future time all blocks up to [99984,99999] have been 1275bd8deadSopenharmony_ciallocated, allocations of blocks of 16 values will continue in an upward 1285bd8deadSopenharmony_cidirection, skipping over any block of 16 values that contains one or 1295bd8deadSopenharmony_cimore values from a currently allocated 1000-value block. 1305bd8deadSopenharmony_ci 1315bd8deadSopenharmony_ci<p> Last modified August 13, 2006 by Jon Leech 1325bd8deadSopenharmony_ci</body> 1335bd8deadSopenharmony_ci</html> 134