1<html> 2 3<head> 4<title>OpenGL Enumerant Allocation Policies</title> 5</head> 6 7<body> 8<h1>OpenGL Enumerant Allocation Policies</h1> 9 10<p> If an OpenGL vendor defines a single-vendor OpenGL or GLX extension 11 that requires one or more new enumerant values, then each of those 12 values must be contained in a block of enumerant values that has 13 been allocated by Khronos for the exclusive use of that vendor. 14 Khronos maintains a registry of such allocations. To allocate 15 enumerants, file a request against project 'registry' in the Khronos 16 Bugzilla. If you are unable to access Bugzilla, you may submit a 17 request via email to "registry 'at' khronos.org". However, 18 response time to email requests is unpredictable. 19 20<p> OpenGL and OpenGL ES use enumerant values in the range [0,24575], as 21 well as reusing some enumerant values in the range [32768,65535]. 22 The latter values were initially assigned to extensions which later 23 became part of the OpenGL core. Enumerant values are grouped into 24 blocks of 16 values, and each block begins with a value that is a 25 multiple of 16. Most blocks in the range [0,24575] are unused, and 26 reserved for use with future versions of OpenGL. 27 28<p> Historically, enumerant values for some single-vendor extensions 29 were allocated in blocks of 1000, beginning with the block 30 [102000,102999] and progressing upward. Values in this range cannot 31 be represented as 16-bit unsigned integers. This imposes a 32 significant and unnecessary performance penalty on some 33 implementations. Such blocks that have already been allocated to 34 vendors will remain allocated unless and until the vendor 35 voluntarily releases the entire block, but no further blocks in this 36 range will be allocated. 37 38<h3>Allocating Enumerants</h3> 39 40<p> Enumerant values for single-vendor extensions will be allocated upon 41 request in blocks of 16 values, beginning with the block 42 [32768,32783] and progressing upward. There are a limited number of 43 available blocks in the more desirable 16-bit range [32768,65535], 44 so do not request enumerants until you actually require them to ship 45 an extension, or request more than you need. 46 47 48<p> Vendors must adhere to the following guidelines for requesting and 49 using enumerants: 50 51<ul> 52 53<li> No extension can be shipped using OpenGL or GLX enumerant values 54 that have not been allocated by the Registrar. 55 56<li> The Registrar will allocate official enumerant values for an 57 extension only when there is a commitment to release that extension. 58 Prior to this point, development work on the extension should be 59 done using temporarily assigned enumerant values. Enumerant values 60 in the range [0x6000,0x7FFF] (e.g. [24576,32767] are reserved for 61 temporary use, and will never be assigned to any shipping core or 62 extension enumerant. 63 64<li> An extension specification, following the <a 65 href="template.html">template</a>, must exist prior to releasing an 66 extension. The specification will ideally include all fields from 67 the template; if this is proving difficult due to lack of 68 familiarity with the appropriate API Specification, please consult 69 with other implementers on the corresponding Khronos Working Group 70 mailing list. Vendors are strongly encouraged to submit this 71 specification to the registry. 72 73<li> Minimize the number of unused enumerant values in an allocated 74 block. 75 76<li> Do not request blocks solely to reserve enumerants against 77 anticipated future use. If you are likely to need a large contiguous 78 block of enumerants in the future, this should be discussed with the 79 Registrar. 80 81<li> If a vendor determines that it does not need a block of enumerant 82 values that has been previously allocated to that vendor, the vendor 83 may voluntarily return the entire block for future reallocation. 84 85<li> If an extension is promoted from single-vendor to multi-vendor 86 <tt>EXT</tt> or <tt>ARB</tt> status, the following rule applies: for 87 each enumerant that is present in both the single-vendor version and 88 the multi-vendor version, a new multi-vendor extension enumerant 89 will be defined with the same value as the single-vendor extension 90 enumerant. The name of the new enumerant will be the name of the 91 extension enumerant with the suffix <tt>EXT</tt> or <tt>ARB</tt> 92 replacing the vendor-specific suffix. 93 94 <p> Here, <i>promoted</i> is taken to mean that use of the 95 single-vendor and multi-vendor enumerants is semantically 96 equivalent, e.g. the effects of such use on GL and framebuffer state 97 are identical. If this is not true, new values should be assigned to 98 the multi-vendor enumerants. The intent is that it should be 99 possible for the single-vendor and multi-vendor versions of the 100 extension to coexist in a single implementation. 101 102<li> If an extension becomes part of a new version of OpenGL, 103 the following rule applies: for each enumerant that is present in 104 both the extension and the new version of OpenGL, the ARB will 105 choose one of the following two options: 106 107 <ul> 108 <li> Define a new OpenGL enumerant with the same value as the 109 extension enumerant. The name of the new enumerant will be the 110 name of the extension enumerant with the extension suffix 111 deleted. 112 113 <li> Define a new OpenGL enumerant with a previously unused value in 114 the range [0,32767]. The name of the new enumerant will be the 115 name of the extension enumerant with the extension suffix 116 deleted. 117 </ul> 118 119<li> If a group of vendors introduces an extension, one of the vendors 120 in the group must be designated as the "lead vendor" for that 121 extension. The lead vendor will then allocate enumerant values for 122 the extension in the same way that it would allocate enumerant 123 values for a single-vendor extension. 124</ul> 125 126<p> If at some future time all blocks up to [99984,99999] have been 127allocated, allocations of blocks of 16 values will continue in an upward 128direction, skipping over any block of 16 values that contains one or 129more values from a currently allocated 1000-value block. 130 131<p> Last modified August 13, 2006 by Jon Leech 132</body> 133</html> 134