1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
<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>
|
