windows-xp/Source/XPSP1/NT/multimedia/opengl/exts/registry/enualloc.txt

-------------------------------------------------------------------------------
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