mirror of
https://github.com/openharmony/third_party_opengles.git
synced 2026-07-18 16:54:35 -04:00
lizheng
134 lines
6.1 KiB
HTML
134 lines
6.1 KiB
HTML
<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>
|