The set of functions with static dispatch is (supposed to be) defined by
the Linux OpenGL ABI. We export quite a few more functions than that
for historical reasons. However, this list should never grow.
This table is used instead of the static_dispatch tag in the XML to
generate the static dispatch functions. I used
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
before and after the change. diff showed no differences.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
Since the set of functions with static will never change, there is no
reason to store it in the XML. It's just one of those fields that
confuses people adding new functions.
This is split out from the rest of the series so that in-code assertions
can be used to verify that the data in the Python code matches the XML.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
It is quite hard to meet the dependency of the libxml2 python bindings
outside Linux, and in particularly on MacOSX; whereas ElementTree is
part of Python's standard library. ElementTree is more limited than
libxml2: no DTD verification, defaults from DTD, or XInclude support,
but none of these limitations is serious enough to justify using
libxml2.
In fact, it was easier to refactor the code to use ElementTree than to
try to get libxml2 python bindings.
In the process, gl_item_factory class was refactored so that there is
one method for each kind of object to be created, as it simplifies
things substantially.
I confirmed that precisely the same output is generated for GL/GLX/GLES.
v2: Remove m4/ax_python_module.m4 as suggested by Matt Turner.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This bug is currently benign, since get_called_parameter_string() is
currently only used for functions that return true for
glx_function.has_different_protocol(), and none of those functions
include padding. However, in order to implement marshalling of GL API
functions, we'll need to use get_called_parameter_string() far more
often.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we used the mesa_name XML attribute to make the code
generation scripts aware of any instances where the Mesa
implementation of a function had a different function name suffix than
the primary name in the XML. Now that all of the Mesa implementation
functions have been renamed to match the XML, this attribute is no
longer necessary.
Acked-by: Brian Paul <brianp@vmware.com>
This patch updates gl_XML.py to parse the new XML attributes "exec",
"desktop", "deprecated", and "mesa_name", which will be needed to code
generate _mesa_create_exec_table().
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
gl_XML.py's gl_function class keeps track of an entry_point_api_map
property that tracks, for each set of aliased functions, which ES1 or
ES2 version the given function name first appeared in.
This patch aggregates that information together across aliased
functions, into an easier-to-use api_map property.
Future patches will use this information when code generating
_mesa_create_exec_table(), to determine which set of dispatch table
entries should be populated based on the API.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously, when code-generating aliased functions in glapitemp.h, we
weren't consistent about which function alias we used to obtain the
parameter names, with the risk that we would generate incorrect code
like this:
KEYWORD1 void KEYWORD2 NAME(Foo)(GLint x)
{
(void) x;
DISPATCH(Foo, (x), (F, "glFoo(%d);\n", x));
}
KEYWORD1 void KEYWORD2 NAME(FooEXT)(GLint y)
{
(void) x;
DISPATCH(Foo, (x), (F, "glFooEXT(%d);\n", x));
}
At the moment there are no aliased functions with mismatched parameter
names, so this isn't the problem. But when we introduce GLES1
functions into the dispatch table, there will be
(MapBufferRange/MapBufferRangeEXT). This patch paves the way for that
by fixing the code generation script to handle the mismatch correctly.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
An unfortunate quirk of Python 2 is that there are two types of
classes: "classic" classes (which are backward compatible with some
unfortunate design decisions made early in Python's history), and
"new-style" classes. Classic classes have a number of limitations
(for example they don't support super()) and are unavailable in Python
3. There's really no reason to use classic classes, except in
unmaintained legacy code. For more information see
http://www.python.org/download/releases/2.2.3/descrintro/.
This patch upgrades the Python code in src/mapi/glapi/gen to use
exclusively new-style classes.
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This brings us into accordance with the official Python style guide
(http://www.python.org/dev/peps/pep-0008/#indentation).
To preserve the indentation of the c code that is generated by these
scripts, I've avoided re-indenting triple-quoted strings (unless those
strings appear to be docstrings).
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
add gl_api::filter_functions and gl_function::filter_entry_points to
filter out unwanted functions and entry points.
Reviewed-by: Brian Paul <brianp@vmware.com>
