| <html> |
| |
| <head> |
| <title>OpenGL Enumerant Allocation Policies</title> |
| </head> |
| |
| <body> |
| <h1>OpenGL Enumerant Allocation Policies</h1> |
| |
| <p> If an OpenGL vendor defines a single-vendor OpenGL or GLX extension |
| that requires one or more new enumerant values, then each of those |
| values must be contained in a block of enumerant values that has |
| been allocated by Khronos for the exclusive use of that vendor. |
| Khronos maintains a registry of such allocations. To allocate |
| enumerants, file a request against project 'registry' in the Khronos |
| Bugzilla. If you are unable to access Bugzilla, you may submit a |
| request via email to "registry 'at' khronos.org". However, |
| response time to email requests is unpredictable. |
| |
| <p> OpenGL and OpenGL ES use enumerant values in the range [0,24575], as |
| well as reusing some enumerant values in the range [32768,65535]. |
| The latter values were initially assigned to extensions which later |
| became part of the OpenGL core. Enumerant values are grouped into |
| blocks of 16 values, and each block begins with a value that is a |
| multiple of 16. Most blocks in the range [0,24575] are unused, and |
| reserved for use with future versions of OpenGL. |
| |
| <p> Historically, enumerant values for some single-vendor extensions |
| were allocated in blocks of 1000, beginning with the block |
| [102000,102999] and progressing upward. Values in this range cannot |
| be represented as 16-bit unsigned integers. This imposes a |
| significant and unnecessary performance penalty on some |
| implementations. Such blocks that have already been allocated to |
| vendors will remain allocated unless and until the vendor |
| voluntarily releases the entire block, but no further blocks in this |
| range will be allocated. |
| |
| <h3>Allocating Enumerants</h3> |
| |
| <p> Enumerant values for single-vendor extensions will be allocated upon |
| request in blocks of 16 values, beginning with the block |
| [32768,32783] and progressing upward. There are a limited number of |
| available blocks in the more desirable 16-bit range [32768,65535], |
| so do not request enumerants until you actually require them to ship |
| an extension, or request more than you need. |
| |
| |
| <p> Vendors must adhere to the following guidelines for requesting and |
| using enumerants: |
| |
| <ul> |
| |
| <li> No extension can be shipped using OpenGL or GLX enumerant values |
| that have not been allocated by the Registrar. |
| |
| <li> The Registrar will allocate official enumerant values for an |
| extension only when there is a commitment to release that extension. |
| Prior to this point, development work on the extension should be |
| done using temporarily assigned enumerant values. Enumerant values |
| in the range [0x6000,0x7FFF] (e.g. [24576,32767] are reserved for |
| temporary use, and will never be assigned to any shipping core or |
| extension enumerant. |
| |
| <li> An extension specification, following the <a |
| href="template.html">template</a>, must exist prior to releasing an |
| extension. The specification will ideally include all fields from |
| the template; if this is proving difficult due to lack of |
| familiarity with the appropriate API Specification, please consult |
| with other implementers on the corresponding Khronos Working Group |
| mailing list. Vendors are strongly encouraged to submit this |
| specification to the registry. |
| |
| <li> Minimize the number of unused enumerant values in an allocated |
| block. |
| |
| <li> Do not request blocks solely to reserve enumerants against |
| anticipated future use. If you are likely to need a large contiguous |
| block of enumerants in the future, this should be discussed with the |
| Registrar. |
| |
| <li> If a vendor determines that it does not need a block of enumerant |
| values that has been previously allocated to that vendor, the vendor |
| may voluntarily return the entire block for future reallocation. |
| |
| <li> If an extension is promoted from single-vendor to multi-vendor |
| <tt>EXT</tt> or <tt>ARB</tt> status, the following rule applies: for |
| each enumerant that is present in both the single-vendor version and |
| the multi-vendor version, a new multi-vendor extension enumerant |
| will be defined with the same value as the single-vendor extension |
| enumerant. The name of the new enumerant will be the name of the |
| extension enumerant with the suffix <tt>EXT</tt> or <tt>ARB</tt> |
| replacing the vendor-specific suffix. |
| |
| <p> Here, <i>promoted</i> is taken to mean that use of the |
| single-vendor and multi-vendor enumerants is semantically |
| equivalent, e.g. the effects of such use on GL and framebuffer state |
| are identical. If this is not true, new values should be assigned to |
| the multi-vendor enumerants. The intent is that it should be |
| possible for the single-vendor and multi-vendor versions of the |
| extension to coexist in a single implementation. |
| |
| <li> If an extension becomes part of a new version of OpenGL, |
| the following rule applies: for each enumerant that is present in |
| both the extension and the new version of OpenGL, the ARB will |
| choose one of the following two options: |
| |
| <ul> |
| <li> Define a new OpenGL enumerant with the same value as the |
| extension enumerant. The name of the new enumerant will be the |
| name of the extension enumerant with the extension suffix |
| deleted. |
| |
| <li> Define a new OpenGL enumerant with a previously unused value in |
| the range [0,32767]. The name of the new enumerant will be the |
| name of the extension enumerant with the extension suffix |
| deleted. |
| </ul> |
| |
| <li> If a group of vendors introduces an extension, one of the vendors |
| in the group must be designated as the "lead vendor" for that |
| extension. The lead vendor will then allocate enumerant values for |
| the extension in the same way that it would allocate enumerant |
| values for a single-vendor extension. |
| </ul> |
| |
| <p> If at some future time all blocks up to [99984,99999] have been |
| allocated, allocations of blocks of 16 values will continue in an upward |
| direction, skipping over any block of 16 values that contains one or |
| more values from a currently allocated 1000-value block. |
| |
| <p> Last modified August 13, 2006 by Jon Leech |
| </body> |
| </html> |