2005-02-22 15:39:46 +00:00
|
|
|
|
2015-02-09 22:18:30 +00:00
|
|
|
# (C) Copyright Zack Rusin 2005. All Rights Reserved.
|
|
|
|
# Copyright (C) 2015 Intel Corporation
|
2015-09-18 00:10:28 +01:00
|
|
|
# Copyright (C) 2015 Broadcom Corporation
|
2018-09-14 20:57:32 +01:00
|
|
|
#
|
2005-02-22 15:39:46 +00:00
|
|
|
# Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
# copy of this software and associated documentation files (the "Software"),
|
|
|
|
# to deal in the Software without restriction, including without limitation
|
|
|
|
# on the rights to use, copy, modify, merge, publish, distribute, sub
|
|
|
|
# license, and/or sell copies of the Software, and to permit persons to whom
|
|
|
|
# the Software is furnished to do so, subject to the following conditions:
|
|
|
|
#
|
|
|
|
# The above copyright notice and this permission notice (including the next
|
|
|
|
# paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
# Software.
|
|
|
|
#
|
|
|
|
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
# IBM AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
# IN THE SOFTWARE.
|
|
|
|
#
|
|
|
|
# Authors:
|
|
|
|
# Zack Rusin <zack@kde.org>
|
|
|
|
|
2015-02-09 22:18:30 +00:00
|
|
|
import argparse
|
|
|
|
|
2005-02-22 15:39:46 +00:00
|
|
|
import license
|
|
|
|
import gl_XML
|
2015-09-18 00:10:28 +01:00
|
|
|
import xml.etree.ElementTree as ET
|
2005-02-22 15:39:46 +00:00
|
|
|
import sys, getopt
|
2015-09-18 00:10:28 +01:00
|
|
|
import re
|
2005-02-22 15:39:46 +00:00
|
|
|
|
Mammoth update to the Python code generator scripts that live in
src/mesa/glapi. Basically, the scripts that did simple things (like
gl_offsets.py) were simple, and the scripts that did more complicated things
(like glX_proto_send.py) were getting progressively more and more out of
control. So, I re-write the foundation classes on which everything is based.
One problem with the existing code is that the division between the GL API
database representation and the way the output code is generated was either
blury or nonexistant. The new code somewhat follows the
Model-View-Controller pattern, minus the Controller. There is a distinct
set of classes that model the API data, and there is a distinct set of
classes that generate code from that data.
One big change is in the class that represents GL functions (was glFunction,
is now gl_function). There used to be an instance of this calls for each
function and for each alias to that function. For example, there was an
instance for PointParameterivSGIS, PointParameterivEXT, PointParameterivARB,
and PointParameteriv. In the new code, there is one instance. Each
instance has a list of entrypoint names for the function. In the next
revision, this will allow a couple useful things. The script will be able
to verify that the parameters, return type, and GLX protocol for a function
and all it's aliases match.
It will also allow aliases to be represented in the XML more compactly.
Instead of repeating all the information, an alias can be listed as:
<function name="PointParameterivARB" alias="PointParameterivEXT"/>
Because the data representation was changed, the order that the alias
functions are processed by the scripts also changed. This accounts for at
least 2,700 of the ~3,600 lines of diffs in the generated code.
Most of the remaining ~900 lines of diffs are the result of bugs *fixed* by
the new scripts. The old scripts also generated code with some bugs in it.
These bugs were discovered while the new code was being written.
These changes were discussed on the mesa3d-dev mailing list back at the end
of May:
http://marc.theaimsgroup.com/?t=111714569000004&r=1&w=2
Xorg bug: 3197, 3208
2005-06-22 00:42:43 +01:00
|
|
|
class PrintGlEnums(gl_XML.gl_print_base):
|
2005-02-22 15:39:46 +00:00
|
|
|
|
2012-10-10 15:20:57 +01:00
|
|
|
def __init__(self):
|
|
|
|
gl_XML.gl_print_base.__init__(self)
|
2005-05-26 17:59:47 +01:00
|
|
|
|
2012-10-10 15:20:57 +01:00
|
|
|
self.name = "gl_enums.py (from Mesa)"
|
|
|
|
self.license = license.bsd_license_template % ( \
|
2005-02-22 15:39:46 +00:00
|
|
|
"""Copyright (C) 1999-2005 Brian Paul All Rights Reserved.""", "BRIAN PAUL")
|
2015-09-18 00:10:28 +01:00
|
|
|
# Mapping from enum value to (name, priority) tuples.
|
2012-10-10 15:20:57 +01:00
|
|
|
self.enum_table = {}
|
2015-09-18 00:10:28 +01:00
|
|
|
# Mapping from enum name to value
|
|
|
|
self.string_to_int = {}
|
2012-10-10 15:20:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
def printRealHeader(self):
|
2019-12-09 18:54:16 +00:00
|
|
|
print('#include <stdio.h>')
|
2018-07-05 14:17:32 +01:00
|
|
|
print('#include "main/glheader.h"')
|
|
|
|
print('#include "main/enums.h"')
|
|
|
|
print('#include "main/mtypes.h"')
|
|
|
|
print('')
|
|
|
|
print('typedef struct PACKED {')
|
|
|
|
print(' uint32_t offset;')
|
|
|
|
print(' int n;')
|
|
|
|
print('} enum_elt;')
|
|
|
|
print('')
|
2012-10-10 15:20:57 +01:00
|
|
|
return
|
|
|
|
|
|
|
|
def print_code(self):
|
2018-07-05 14:17:32 +01:00
|
|
|
print("""
|
2005-02-22 15:39:46 +00:00
|
|
|
typedef int (*cfunc)(const void *, const void *);
|
|
|
|
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
/**
|
2013-09-19 20:06:54 +01:00
|
|
|
* Compare a key enum value to an element in the \c enum_string_table_offsets array.
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
*
|
|
|
|
* \c bsearch always passes the key as the first parameter and the pointer
|
|
|
|
* to the array element as the second parameter. We can elimiate some
|
|
|
|
* extra work by taking advantage of that fact.
|
|
|
|
*
|
|
|
|
* \param a Pointer to the desired enum name.
|
2013-09-19 20:06:54 +01:00
|
|
|
* \param b Pointer into the \c enum_string_table_offsets array.
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
*/
|
2013-09-19 20:06:54 +01:00
|
|
|
static int compar_nr( const int *a, enum_elt *b )
|
2005-02-22 15:39:46 +00:00
|
|
|
{
|
2013-09-19 20:06:54 +01:00
|
|
|
return a[0] - b->n;
|
2005-02-22 15:39:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-02-23 16:36:17 +00:00
|
|
|
static char token_tmp[20];
|
2005-02-22 15:39:46 +00:00
|
|
|
|
2016-08-11 16:28:57 +01:00
|
|
|
/**
|
|
|
|
* This function always returns a string. If the number is a valid enum, it
|
|
|
|
* returns the enum name. Otherwise, it returns a numeric string.
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
_mesa_enum_to_string(int nr)
|
2005-02-22 15:39:46 +00:00
|
|
|
{
|
2013-09-23 22:07:15 +01:00
|
|
|
enum_elt *elt;
|
|
|
|
|
2014-09-22 06:50:36 +01:00
|
|
|
elt = bsearch(& nr, enum_string_table_offsets,
|
2015-02-28 16:11:29 +00:00
|
|
|
ARRAY_SIZE(enum_string_table_offsets),
|
2014-09-22 06:50:36 +01:00
|
|
|
sizeof(enum_string_table_offsets[0]),
|
|
|
|
(cfunc) compar_nr);
|
2005-02-22 15:39:46 +00:00
|
|
|
|
2013-09-19 20:06:54 +01:00
|
|
|
if (elt != NULL) {
|
|
|
|
return &enum_string_table[elt->offset];
|
2005-02-23 16:36:17 +00:00
|
|
|
}
|
|
|
|
else {
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
/* this is not re-entrant safe, no big deal here */
|
2019-12-09 18:54:16 +00:00
|
|
|
snprintf(token_tmp, sizeof(token_tmp) - 1, "0x%x", nr);
|
2010-07-13 14:44:35 +01:00
|
|
|
token_tmp[sizeof(token_tmp) - 1] = '\\0';
|
2005-02-23 16:36:17 +00:00
|
|
|
return token_tmp;
|
|
|
|
}
|
2005-02-22 15:39:46 +00:00
|
|
|
}
|
|
|
|
|
2011-01-20 16:38:49 +00:00
|
|
|
/**
|
|
|
|
* Primitive names
|
|
|
|
*/
|
2013-05-02 02:15:32 +01:00
|
|
|
static const char *prim_names[PRIM_MAX+3] = {
|
2011-01-20 16:38:49 +00:00
|
|
|
"GL_POINTS",
|
|
|
|
"GL_LINES",
|
|
|
|
"GL_LINE_LOOP",
|
|
|
|
"GL_LINE_STRIP",
|
|
|
|
"GL_TRIANGLES",
|
|
|
|
"GL_TRIANGLE_STRIP",
|
|
|
|
"GL_TRIANGLE_FAN",
|
|
|
|
"GL_QUADS",
|
|
|
|
"GL_QUAD_STRIP",
|
|
|
|
"GL_POLYGON",
|
2013-05-02 02:15:32 +01:00
|
|
|
"GL_LINES_ADJACENCY",
|
|
|
|
"GL_LINE_STRIP_ADJACENCY",
|
|
|
|
"GL_TRIANGLES_ADJACENCY",
|
|
|
|
"GL_TRIANGLE_STRIP_ADJACENCY",
|
2014-03-07 08:59:11 +00:00
|
|
|
"GL_PATCHES",
|
2011-01-20 16:38:49 +00:00
|
|
|
"outside begin/end",
|
|
|
|
"unknown state"
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2009-07-02 13:28:20 +01:00
|
|
|
/* Get the name of an enum given that it is a primitive type. Avoids
|
|
|
|
* GL_FALSE/GL_POINTS ambiguity and others.
|
|
|
|
*/
|
2011-01-20 16:38:49 +00:00
|
|
|
const char *
|
|
|
|
_mesa_lookup_prim_by_nr(GLuint nr)
|
2009-07-02 13:28:20 +01:00
|
|
|
{
|
2015-02-28 16:11:29 +00:00
|
|
|
if (nr < ARRAY_SIZE(prim_names))
|
2011-01-20 16:38:49 +00:00
|
|
|
return prim_names[nr];
|
|
|
|
else
|
|
|
|
return "invalid mode";
|
2009-07-02 13:28:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-07-05 14:17:32 +01:00
|
|
|
""")
|
2012-10-10 15:20:57 +01:00
|
|
|
return
|
2005-02-22 15:39:46 +00:00
|
|
|
|
Mammoth update to the Python code generator scripts that live in
src/mesa/glapi. Basically, the scripts that did simple things (like
gl_offsets.py) were simple, and the scripts that did more complicated things
(like glX_proto_send.py) were getting progressively more and more out of
control. So, I re-write the foundation classes on which everything is based.
One problem with the existing code is that the division between the GL API
database representation and the way the output code is generated was either
blury or nonexistant. The new code somewhat follows the
Model-View-Controller pattern, minus the Controller. There is a distinct
set of classes that model the API data, and there is a distinct set of
classes that generate code from that data.
One big change is in the class that represents GL functions (was glFunction,
is now gl_function). There used to be an instance of this calls for each
function and for each alias to that function. For example, there was an
instance for PointParameterivSGIS, PointParameterivEXT, PointParameterivARB,
and PointParameteriv. In the new code, there is one instance. Each
instance has a list of entrypoint names for the function. In the next
revision, this will allow a couple useful things. The script will be able
to verify that the parameters, return type, and GLX protocol for a function
and all it's aliases match.
It will also allow aliases to be represented in the XML more compactly.
Instead of repeating all the information, an alias can be listed as:
<function name="PointParameterivARB" alias="PointParameterivEXT"/>
Because the data representation was changed, the order that the alias
functions are processed by the scripts also changed. This accounts for at
least 2,700 of the ~3,600 lines of diffs in the generated code.
Most of the remaining ~900 lines of diffs are the result of bugs *fixed* by
the new scripts. The old scripts also generated code with some bugs in it.
These bugs were discovered while the new code was being written.
These changes were discussed on the mesa3d-dev mailing list back at the end
of May:
http://marc.theaimsgroup.com/?t=111714569000004&r=1&w=2
Xorg bug: 3197, 3208
2005-06-22 00:42:43 +01:00
|
|
|
|
2015-09-18 00:10:28 +01:00
|
|
|
def printBody(self, xml):
|
|
|
|
self.process_enums(xml)
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
|
2015-09-18 00:10:28 +01:00
|
|
|
sorted_enum_values = sorted(self.enum_table.keys())
|
2012-10-10 15:20:57 +01:00
|
|
|
string_offsets = {}
|
|
|
|
i = 0;
|
2018-07-05 14:17:32 +01:00
|
|
|
print('#if defined(__GNUC__)')
|
|
|
|
print('# define LONGSTRING __extension__')
|
|
|
|
print('#else')
|
|
|
|
print('# define LONGSTRING')
|
|
|
|
print('#endif')
|
|
|
|
print('')
|
|
|
|
print('LONGSTRING static const char enum_string_table[] = {')
|
2015-12-01 20:02:05 +00:00
|
|
|
# We express the very long concatenation of enum strings as an array
|
|
|
|
# of characters rather than as a string literal to work-around MSVC's
|
|
|
|
# 65535 character limit.
|
2015-09-18 00:10:28 +01:00
|
|
|
for enum in sorted_enum_values:
|
|
|
|
(name, pri) = self.enum_table[enum]
|
2018-07-05 14:17:32 +01:00
|
|
|
print(" ", end=' ')
|
2015-12-01 20:02:05 +00:00
|
|
|
for ch in name:
|
2018-07-05 14:17:32 +01:00
|
|
|
print("'%c'," % ch, end=' ')
|
|
|
|
print("'\\0',")
|
2015-12-01 20:02:05 +00:00
|
|
|
|
2013-09-19 20:06:54 +01:00
|
|
|
string_offsets[ enum ] = i
|
2012-10-10 15:20:57 +01:00
|
|
|
i += len(name) + 1
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
|
2018-07-05 14:17:32 +01:00
|
|
|
print('};')
|
|
|
|
print('')
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
|
|
|
|
|
2018-07-05 14:17:32 +01:00
|
|
|
print('static const enum_elt enum_string_table_offsets[%u] =' % (len(self.enum_table)))
|
|
|
|
print('{')
|
2015-09-18 00:10:28 +01:00
|
|
|
for enum in sorted_enum_values:
|
|
|
|
(name, pri) = self.enum_table[enum]
|
2018-07-05 14:17:32 +01:00
|
|
|
print(' { %5u, 0x%08X }, /* %s */' % (string_offsets[enum], enum, name))
|
|
|
|
print('};')
|
|
|
|
print('')
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
|
2012-10-10 15:20:57 +01:00
|
|
|
self.print_code()
|
|
|
|
return
|
2005-02-22 15:39:46 +00:00
|
|
|
|
2015-09-18 00:10:28 +01:00
|
|
|
def add_enum_provider(self, name, priority):
|
|
|
|
value = self.string_to_int[name]
|
|
|
|
|
|
|
|
# We don't want the weird GL_SKIP_COMPONENTS1_NV enums.
|
|
|
|
if value < 0:
|
|
|
|
return
|
|
|
|
# We don't want the 64-bit GL_TIMEOUT_IGNORED "enums"
|
|
|
|
if value > 0xffffffff:
|
|
|
|
return
|
|
|
|
|
2015-11-26 01:00:00 +00:00
|
|
|
# We don't want bitfields in the enum-to-string table --
|
|
|
|
# individual bits have so many names, it's pointless. Note
|
|
|
|
# that we check for power-of-two, since some getters have
|
|
|
|
# "_BITS" in their name, but none have a power-of-two enum
|
|
|
|
# number.
|
|
|
|
if not (value & (value - 1)) and '_BIT' in name:
|
|
|
|
return
|
|
|
|
|
|
|
|
# Also drop the GL_*_ATTRIB_BITS bitmasks.
|
|
|
|
if value == 0xffffffff:
|
|
|
|
return
|
2015-09-18 00:10:28 +01:00
|
|
|
|
|
|
|
if value in self.enum_table:
|
|
|
|
(n, p) = self.enum_table[value]
|
|
|
|
if priority < p:
|
|
|
|
self.enum_table[value] = (name, priority)
|
|
|
|
else:
|
|
|
|
self.enum_table[value] = (name, priority)
|
|
|
|
|
|
|
|
def process_extension(self, extension):
|
|
|
|
if extension.get('name').startswith('GL_ARB_'):
|
|
|
|
extension_prio = 400
|
|
|
|
elif extension.get('name').startswith('GL_EXT_'):
|
|
|
|
extension_prio = 600
|
|
|
|
else:
|
|
|
|
extension_prio = 800
|
|
|
|
|
|
|
|
for enum in extension.findall('require/enum'):
|
|
|
|
self.add_enum_provider(enum.get('name'), extension_prio)
|
|
|
|
|
|
|
|
def process_enums(self, xml):
|
|
|
|
# First, process the XML entries that define the hex values
|
|
|
|
# for all of the enum names.
|
|
|
|
for enum in xml.findall('enums/enum'):
|
|
|
|
name = enum.get('name')
|
|
|
|
value = int(enum.get('value'), base=16)
|
|
|
|
|
|
|
|
# If the same name ever maps to multiple values, that can
|
|
|
|
# confuse us. GL_ACTIVE_PROGRAM_EXT is OK to lose because
|
|
|
|
# we choose GL_ACTIVE PROGRAM instead.
|
|
|
|
if name in self.string_to_int and name != "GL_ACTIVE_PROGRAM_EXT":
|
2018-07-05 14:17:32 +01:00
|
|
|
print("#error Renumbering {0} from {1} to {2}".format(name, self.string_to_int[name], value))
|
2015-09-18 00:10:28 +01:00
|
|
|
|
|
|
|
self.string_to_int[name] = value
|
|
|
|
|
|
|
|
# Now, process all of the API versions and extensions that
|
|
|
|
# provide enums, so we can decide what name to call any hex
|
|
|
|
# value.
|
|
|
|
for feature in xml.findall('feature'):
|
|
|
|
feature_name = feature.get('name')
|
|
|
|
|
2015-11-26 01:04:21 +00:00
|
|
|
# When an enum gets renamed in a newer version (generally
|
|
|
|
# because of some generalization of the functionality),
|
|
|
|
# prefer the newer name. Also, prefer desktop GL names to
|
|
|
|
# ES.
|
2015-09-18 00:10:28 +01:00
|
|
|
m = re.match('GL_VERSION_([0-9])_([0-9])', feature_name)
|
|
|
|
if m:
|
2015-11-26 01:04:21 +00:00
|
|
|
feature_prio = 100 - int(m.group(1) + m.group(2))
|
2015-09-18 00:10:28 +01:00
|
|
|
else:
|
|
|
|
m = re.match('GL_ES_VERSION_([0-9])_([0-9])', feature_name)
|
|
|
|
if m:
|
2015-11-26 01:04:21 +00:00
|
|
|
feature_prio = 200 - int(m.group(1) + m.group(2))
|
2015-09-18 00:10:28 +01:00
|
|
|
else:
|
|
|
|
feature_prio = 200
|
|
|
|
|
|
|
|
for enum in feature.findall('require/enum'):
|
|
|
|
self.add_enum_provider(enum.get('name'), feature_prio)
|
|
|
|
|
|
|
|
for extension in xml.findall('extensions/extension'):
|
|
|
|
self.process_extension(extension)
|
Fairly significant changes to enums.c and the way it is generated. enums.c
now contains 3 static tables. The first table is a single, large string of
all the enum names. The second table is an array, sorted by enum name, of
indexes to the string table and the matching enum value. The extra string
table is used to eliminate relocs (and save space) in the compiled file.
The third table is an array, sorted by enum value, of indexes into the
second table.
The [name, enum] table contains all of the enums, but the table sorted by
enum-value does not. This table contains one entry per enum value. For
enum values that have multiple names (e.g., 0x84C0 has GL_TEXTURE0_ARB and
GL_TEXTURE0), only an index to the "best" name will appear in the table.
gl_enums.py gives precedence to "core" GL versions of names, followed by ARB
versions, followed by EXT versions, followed, finally, by vendor versions
(i.e., anything that doesn't fall into one of the previous categories). By
filtering the unneeded elements from this table, not only can we guarantee
determinism in the generated tables, but we save 364 elements in the table.
The optimizations outlined above reduced the size of the stripped enums.o
(on x86) from ~80KB to ~53KB.
The internal organization of gl_enums.py was also heavily modified.
Previously enums were stored in an unsorted list as [value, name] tuples
(basically). This list was then sorted, using a user-specified compare
function (i.e., VERY slow in most Python implementations) to generate a
table sorted by enum value. It was then sorted again, using another
user-specified compare function, to generate a table sorted by name.
Enums are now stored in a dictionary, called enum_table, with the enum value
as the key. Each dictionary element is a list of [name, priority] pairs.
The priority is determined as described above. The table sorted by enum
value is generated by sorting the keys of enum_table (i.e., very fast). The
tables sorted by name are generated by creating a list, called name_table,
of [name, enum value] pairs. This table can then be sorted by doing
name_table.sort() (i.e., very fast).
The result is a fair amount more Python code, but execution time was reduced
from ~14 seconds to ~2 seconds.
2005-02-26 01:09:35 +00:00
|
|
|
|
|
|
|
|
2015-02-09 22:18:30 +00:00
|
|
|
def _parser():
|
|
|
|
parser = argparse.ArgumentParser()
|
|
|
|
parser.add_argument('-f', '--input_file',
|
|
|
|
required=True,
|
|
|
|
help="Choose an xml file to parse.")
|
|
|
|
return parser.parse_args()
|
2005-02-22 15:39:46 +00:00
|
|
|
|
2012-10-10 15:20:57 +01:00
|
|
|
|
2015-02-09 22:19:23 +00:00
|
|
|
def main():
|
2015-02-09 22:18:30 +00:00
|
|
|
args = _parser()
|
2015-09-18 00:10:28 +01:00
|
|
|
xml = ET.parse(args.input_file)
|
2012-10-10 15:20:57 +01:00
|
|
|
|
|
|
|
printer = PrintGlEnums()
|
2015-09-18 00:10:28 +01:00
|
|
|
printer.Print(xml)
|
2015-02-09 22:19:23 +00:00
|
|
|
|
|
|
|
|
|
|
|
if __name__ == '__main__':
|
|
|
|
main()
|