------------------------------------------------------------------------------- Proposed changes and additions to OpenGL ARB policies for allocating new enumerant values for OpenGL extensions Craig Dunwoody Silicon Graphics 8-10-94 ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- Current policies ------------------------------------------------------------------------------- If an OpenGL vendor defines a single-vendor OpenGL 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 SGI for the exclusive use of that vendor. SGI maintains a registry of such allocations. OpenGL 1.0 uses enumerant values in the range [0,32767]. OpenGL 1.0 enumerant values are grouped into blocks of 16 values. Each block begins with a value that is a multiple of 16. Only 75 of the 2048 blocks in the range [0,32767] are used by OpenGL 1.0; the remaining blocks in this range are reserved for use by future versions of OpenGL. The largest enumerant value used by OpenGL 1.0 is 16391. Enumerant values for single-vendor extensions may be allocated in blocks of 1000, beginning with the block [102000,102999] and progressing upward. ------------------------------------------------------------------------------- Problems with current policies ------------------------------------------------------------------------------- 1. Unlike the OpenGL 1.0 enumerant values, values in the blocks of extension enumerant values that begin with the block [102000,102999] cannot be represented as 16-bit unsigned integers. This imposes a significant and unnecessary performance penalty on some implementations. 2. Current policies are insufficiently explicit about the process by which a vendor may voluntarily return to the registry a block of enumerant values that has been allocated for that vendor's use but has subsequently been determined by the vendor to be unneeded. 3. Current policies are insufficiently explicit about the management of enumerant values for an extension that is introduced by a single vendor, supported at a later date by additional vendors, and eventually incorporated as a required part of a new version of OpenGL. 4. Current policies are insufficiently explicit about the allocation of enumerant values for an extension that is introduced by a group of vendors. ------------------------------------------------------------------------------- Proposed changes to current policies ------------------------------------------------------------------------------- C1. 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. SGI will maintain a registry of such allocations. Because of the limited number (2048) of available blocks in the more desirable 16-bit range [32768,65535], vendors are expected to adhere to the following guidelines: 1. Allocate official enumerant values for an extension only after making a commitment to release that extension. Prior to this point, development work on the extension should be done using temporarily assigned enumerant values. One approach would be to choose these temporary values from the set of values in the range [0,32767] that are not used by the current version of OpenGL. 2. Minimize the number of unused enumerant values in an allocated block. Any block of 1000 enumerant values (beginning with the block [102000,102999] and progressing upward) that has already been allocated to a vendor will remain so allocated unless the vendor voluntarily returns the entire block. New allocations will be done only in blocks of 16 values, beginning with the block [32768,32783] and progressing upward. After the block [99984,99999] has 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. ------------------------------------------------------------------------------- Proposed additions to current policies ------------------------------------------------------------------------------- A1. 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. A2. If an extension progresses from single-vendor status to multi-vendor 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 EXT replacing the vendor-specific suffix. A3. If an extension becomes a required 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: 1. 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. 2. 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. A4. 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. ------------------------------------------------------------------------------- Discussion ------------------------------------------------------------------------------- SGI's position is that these proposed changes and additions to ARB policies would solve the problems listed at the beginning of this document without introducing significant new problems. The centerpiece of the proposal is the idea of dividing the range of most desirable enumerant values (the 16-bit range [0,65535]) into two equal-sized blocks: the block [0,32767] for OpenGL enumerants, and the block [32768,65535] for OpenGL extension enumerants. We claim that this division would provide both OpenGL and OpenGL extensions with a more than adequate supply of enumerant values in the desirable 16-bit range [0,65535]. The basis for our claim is as follows: 1. OpenGL 1.0 uses only 75 of the 2048 blocks of 16 enumerant values in the OpenGL reserved range [0,32767], and nearly all of those 75 blocks are only partially filled. The largest enumerant value used by OpenGL 1.0 is 16391. 2. It is reasonable to expect that most or all of the enumerants that will be added as a mandatory part of future versions of OpenGL will appear first in OpenGL extensions. Since the proposed new policy A4 (see above) would make it possible for an extension to be adopted as a mandatory part of a new version of OpenGL without the need for the allocation of new enumerant values, we expect that it would rarely be necessary to allocate a new enumerant value in the range [0,32767]. 3. SGI's initial release of 9 multi-vendor (EXT) extensions and 3 single-vendor (SGI and SGIS) extensions would require a total of only 9 of the 2048 blocks of 16 enumerant values in the range [32768,65535]. That is less than 0.5% of the available blocks in this range. ------------------------------------------------------------------------------- End of document ------------------------------------------------------------------------------- ------- End of Forwarded Message