mesa/src/mapi/glapi/gen/gl_enums.py

292 lines
9.0 KiB
Python
Raw Normal View History

2005-02-22 15:39:46 +00:00
# (C) Copyright Zack Rusin 2005. All Rights Reserved.
# Copyright (C) 2015 Intel Corporation
# Copyright (C) 2015 Broadcom Corporation
#
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>
import argparse
2005-02-22 15:39:46 +00:00
import license
import gl_XML
import xml.etree.ElementTree as ET
2005-02-22 15:39:46 +00:00
import sys, getopt
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
def __init__(self):
gl_XML.gl_print_base.__init__(self)
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")
# Mapping from enum value to (name, priority) tuples.
self.enum_table = {}
# Mapping from enum name to value
self.string_to_int = {}
def printRealHeader(self):
print('#include <stdio.h>')
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('')
return
def print_code(self):
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
/**
* 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.
* \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
*/
static int compar_nr( const int *a, enum_elt *b )
2005-02-22 15:39:46 +00:00
{
return a[0] - b->n;
2005-02-22 15:39:46 +00:00
}
static char token_tmp[20];
2005-02-22 15:39:46 +00: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
{
enum_elt *elt;
elt = bsearch(& nr, enum_string_table_offsets,
ARRAY_SIZE(enum_string_table_offsets),
sizeof(enum_string_table_offsets[0]),
(cfunc) compar_nr);
2005-02-22 15:39:46 +00:00
if (elt != NULL) {
return &enum_string_table[elt->offset];
}
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 */
snprintf(token_tmp, sizeof(token_tmp) - 1, "0x%x", nr);
token_tmp[sizeof(token_tmp) - 1] = '\\0';
return token_tmp;
}
2005-02-22 15:39:46 +00:00
}
/**
* Primitive names
*/
static const char *prim_names[PRIM_MAX+3] = {
"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",
"GL_LINES_ADJACENCY",
"GL_LINE_STRIP_ADJACENCY",
"GL_TRIANGLES_ADJACENCY",
"GL_TRIANGLE_STRIP_ADJACENCY",
"GL_PATCHES",
"outside begin/end",
"unknown state"
};
/* Get the name of an enum given that it is a primitive type. Avoids
* GL_FALSE/GL_POINTS ambiguity and others.
*/
const char *
_mesa_lookup_prim_by_nr(GLuint nr)
{
if (nr < ARRAY_SIZE(prim_names))
return prim_names[nr];
else
return "invalid mode";
}
""")
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
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
sorted_enum_values = sorted(self.enum_table.keys())
string_offsets = {}
i = 0;
print('#if defined(__GNUC__)')
print('# define LONGSTRING __extension__')
print('#else')
print('# define LONGSTRING')
print('#endif')
print('')
print('LONGSTRING static const char enum_string_table[] = {')
# 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.
for enum in sorted_enum_values:
(name, pri) = self.enum_table[enum]
print(" ", end=' ')
for ch in name:
print("'%c'," % ch, end=' ')
print("'\\0',")
string_offsets[ enum ] = i
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
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
print('static const enum_elt enum_string_table_offsets[%u] =' % (len(self.enum_table)))
print('{')
for enum in sorted_enum_values:
(name, pri) = self.enum_table[enum]
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
self.print_code()
return
2005-02-22 15:39:46 +00: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
# 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
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":
print("#error Renumbering {0} from {1} to {2}".format(name, self.string_to_int[name], value))
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')
# 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.
m = re.match('GL_VERSION_([0-9])_([0-9])', feature_name)
if m:
feature_prio = 100 - int(m.group(1) + m.group(2))
else:
m = re.match('GL_ES_VERSION_([0-9])_([0-9])', feature_name)
if m:
feature_prio = 200 - int(m.group(1) + m.group(2))
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
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
def main():
args = _parser()
xml = ET.parse(args.input_file)
printer = PrintGlEnums()
printer.Print(xml)
if __name__ == '__main__':
main()