When the XML lists one or more GL api functions as aliases for another
GL function, the mesa function that implements the functionality is
usually named after the canonical version of the function (the one
that is the target of the aliases). For example, FogCoordd is listed
as an alias of FogCoorddEXT, and the Mesa function implementing the
functionality is called loopback_FogCoorddEXT.
However, there are exceptions. For example, Enablei is listed as an
alias of EnableIndexedEXT, but the Mesa function implementing the
functionality is called _mesa_EnableIndexed.
To account for these anomalies, this patch annotates the XML with
"mesa_name" attributes, which describe how to adjust the function name
to find the corresponding Mesa function.
For example:
<function name="EnableIndexedEXT" mesa_name="-EXT">...</function>
<function name="IsProgramNV" mesa_name="-NV+ARB">...</function>
means that EnableIndexedEXT is implemented by a Mesa function called
_mesa_EnableIndexed, and IsProgramNV is implemented by a Mesa function
called _mesa_IsProgramARB.
Future patches will use this annotation when code generating
_mesa_create_exec_table(), to determine the name of the Mesa function
that should be stored in each dispatch table entry.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Future patches will use this annotation when code generating
_mesa_create_exec_table(), to determine which functions should be
skipped when the API is desktop GL.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Future patches will use this annotation when code generating
_mesa_create_exec_table(), to determine which functions should be
dispatched to ES-specific implementations. exec="es" indicates that
the ES-specific implementation has a name beginning with "_es_"
(e.g. _es_QueryMatrixxOES), and exec="check" indicates that the
ES-specific implementation has a name beginning with "_check_"
(e.g. _check_GetTexGenxvOES).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Currently, the set of functions which exist in GLES1 or GLES2 is
determined by hardcoded lists of function names in gles_api.py. This
patch encodes that information into the XML files using new
attributes, es1 and es2.
The es1 attribute denotes the first version of GLES 1 in which the
function exists (e.g. es1="1.1" means the function exists in GLES 1.1
but not GLES 1.0). "none" (the default) means the function is not
available in any version of GLES 1.
The es2 attribute denotes the first version of GLES 2/3 in which the
function exists (e.g. es2="2.0" means the function exists in both GLES
2.0 and GLES 3.0). "none" (the default) means the function is not
available in any version of GLES 2 or GLES 3.
Note that since GLES 3 is a strict superset of GLES 2, there is no
need for a separate attribute for it; instead, 'es2="3.0"' should be
used to denote functions that are present in GLES 3 but not GLES 2.
This patch only adds information about GLES versions 1.0, 1.1, and
2.0.
Later patches will modify the python code generation scripts to use
this information rather than the hardcoded lists in gles_api.py.
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
gl_and_es_API.xml defines OpenGL ES 1.1 and 2.0 API as well as OpenGL
API. It consists of gl_API.xml and the newly added es_EXT.xml,
ARB_get_program_binary.xml, OES_single_precision.xml, and
OES_fixed_point.xml.
