163 lines
8.1 KiB
Plaintext
163 lines
8.1 KiB
Plaintext
|
-------------------------------------------------------------------------------
|
||
|
|
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
|
||
|
|
|