OpenGL Enumerant Allocation Policies
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 SGI for the exclusive use of that vendor. SGI maintains a
registry of such allocations. Contact Jon Leech (ljp 'at' sgi.com) or
the current OpenGL ARB Secretary (arb-secretary 'at' sgi.com) to
allocate enumerants.
OpenGL 1.2.1 uses 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.
Historically, enumerant values for some single-vendor extensions
were be 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.
Allocating Enumerants
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 maintains a registry of such allocations.
There are a limited number (2048) of available blocks in the more
desirable 16-bit range [32768,65535].
Vendors must adhere to the following guidelines for requesting
and using enumerants:
- No extension can be shipped using OpenGL or GLX enumerant values
that have not been allocated by SGI.
- SGI 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.
- An extension specification, following the
template, 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 GL Specification, please consult with SGI or
with other OpenGL licensees on the opengl-arb-interest mailing list
to obtain assistance. Vendors are strongly encouraged to submit this
specification to the registry, but are not required to do so.
- Minimize the number of unused enumerant values in an allocated
block. Vendors are strongly encouraged to submit the enumerant names
and corresponding allocated values back to the registry, but are not
required to do so.
- 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
SGI.
- 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.
- If an extension is promoted from single-vendor to multi-vendor
EXT or ARB 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 or ARB
replacing the vendor-specific suffix.
Here, promoted 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.
- 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:
- 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.
- 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.
- 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.
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.
Last modified 3/29/1999 Jon Leech