The function was named badly and wasn't in the dispatch table,
making it hard to find.
Fixes transform_feedback2_states and gets a few other transform
feedback tests closer to working in es3conform.
Reviewed-by Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It's #107, it shouldn't be added after the #116 comment.
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Make sure drivers initialize the version before:
* _mesa_initialize_exec_table is called
* _mesa_initialize_exec_table_vbo is called
* A context is made current
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In glapi/gl_genexec.py:
* Remove _mesa_alloc_dispatch_table call
In glapi/gl_genexec.py and api_exec.h:
* Rename _mesa_create_exec_table to _mesa_initialize_exec_table
In context.c:
* Call _mesa_alloc_dispatch_table instead of _mesa_create_exec_table
* Call _mesa_initialize_exec_table (this is temporary)
Once all drivers have been modified to call
_mesa_initialize_exec_table, then the call to
_mesa_initialize_context can be removed from context.c.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
fixes a regression introduced with
fc9ea7c74d
NOTE: This is a candidate for the 9.0 branch.
Reported-by: Brian Paul <brianp@vmware.com>
Acked-by: Matt Turner <mattst88@gmail.com>
This should help avoid confusion now that we're using the gl_api enum
to distinguishing between core and compatibility API's. The
corresponding enum value for core API's is API_OPENGL_CORE.
Acked-by: Eric Anholt <eric@anholt.net>
Acked-by: Matt Turner <mattst88@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Apparently this was accidentally marked as unimplemented, and thus not
put in the dispatch table.
Fixes 7 es3conform tests:
- copy_buffer_parameters
- copy_buffer_data
- copy_buffer_usage
- pixel_buffer_object_bind
- pixel_buffer_object_parameteriv
- pixel_buffer_object_texture_read
- pixel_buffer_object_usage
v2: Also update the DispatchSanity test for this change.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously, we used these XML annotations to make the code generation
scripts aware of any instances where the Mesa implementation of a
function had a prefix other than "_mesa_". Now that all of the mesa
implementation functions have been renamed to match the XML, we only
need to handle exec="skip", exec="dynamic", and the default case of
exec="mesa".
Acked-by: Brian Paul <brianp@vmware.com>
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 adds the ARB_texture_cube_map_array enums.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch adjusts makefiles to cause src/mesa/main/api_exec.c to be
generated using src/mapi/glapi/gen/gl_genexec.py. There should be no
functional change.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This script generates the file api_exec.c, which contains just the
function _mesa_create_exec_table(), based on the XML files in
src/mapi/glapi/gen.
The following XML attributes, in particular, are used:
- "es1" indicates functions that should be available in ES1 contexts.
- "es2" indicates functions that should be available in ES2/ES3
contexts.
- "exec" indicates which Mesa function should be dispatched to. E.g.
if the GL function is glFoo(), then:
- exec="mesa" (the default) dispatches to _mesa_Foo().
- exec="check" dispatches to _check_Foo().
- exec="es" dispatches to _es_Foo().
- exec="loopback" dispatches to loopback_Foo().
- exec="skip" or exec="dynamic" causes this function to be skipped;
either it is not yet supported ("skip"), or its dispatch table
entry will be dynamically populated based on GL state ("dynamic").
- "desktop" indicates functions that should be available in desktop GL
(non-ES) contexts.
- "deprecated" indicates functions that should not be available in
core contexts.
- "mesa_name" indicates functions whose implementation in Mesa has a
different suffix than the corresponding GL function name.
The generated code looks roughly like this (showing just a single
statement in each block for brevity):
struct _glapi_table *
_mesa_create_exec_table(struct gl_context *ctx)
{
struct _glapi_table *exec;
exec = _mesa_alloc_dispatch_table(_gloffset_COUNT);
if (exec == NULL)
return NULL;
if (_mesa_is_desktop_gl(ctx)) {
SET_ActiveProgramEXT(exec, _mesa_ActiveProgramEXT);
/* other functions not shown */
}
if (_mesa_is_desktop_gl(ctx) || _mesa_is_gles3(ctx)) {
SET_BeginQueryARB(exec, _mesa_BeginQueryARB);
/* other functions not shown */
}
if (_mesa_is_desktop_gl(ctx) || ctx->API == API_OPENGLES) {
SET_GetPointerv(exec, _mesa_GetPointerv);
/* other functions not shown */
}
if (_mesa_is_desktop_gl(ctx) || ctx->API == API_OPENGLES || ctx->API == API_OPENGLES2) {
SET_ActiveTextureARB(exec, _mesa_ActiveTextureARB);
/* other functions not shown */
}
if (_mesa_is_desktop_gl(ctx) || ctx->API == API_OPENGLES2) {
SET_AttachShader(exec, _mesa_AttachShader);
/* other functions not shown */
}
if (ctx->API == API_OPENGL) {
SET_Accum(exec, _mesa_Accum);
/* other functions not shown */
}
if (ctx->API == API_OPENGL || ctx->API == API_OPENGLES) {
SET_AlphaFunc(exec, _mesa_AlphaFunc);
/* other functions not shown */
}
if (ctx->API == API_OPENGLES) {
SET_AlphaFuncxOES(exec, _es_AlphaFuncx);
/* other functions not shown */
}
return exec;
}
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.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>
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>
Future patches will use this annotation when code generating
_mesa_create_exec_table(), to determine which functions should be
dispatched to functions in api_loopback.c.
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 because Mesa dispatches them differently depending on GL
state.
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 because they aren't implemented by Mesa.
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 in core contexts.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We were already doing this for some GLX extensions, but not others.
This patch makes our use of window_system="glX" consistent.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This patch standardizes the category names used in the glapi XML files
to begin each extension name with the prefix "GL_" or "GLX_". There
is no functional change, because these category names are not used in
the generated code.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These functions are part in GL 4.3. Moving this will allow
ProgramParameteriARB to alias ProgramParameteri.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously dispatch table-related code was generated from gl_API.xml,
so it did not include slots for GLES1-only functions (such as those
taking fixed-point arguments).
This patch generates dispatch table-related code from
gl_and_es_API.xml, so that GLES1-only functions are included. This
paves the way for future patches that will unify the GLES1 dispatch
table with the dispatch tables for the other APIs.
The following generated files are affected:
- glapi_x86.S
- glapi_x86-64.S
- glapi_sparc.S
- glprocs.h
- glapitemp.h
- glapitable.h
- glapi_gentable.c
- dispatch.h
- remap_helper.h
Since this change affects makefiles, a full rebuild is required.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Adjust dependencies to ensure that generated files will be rebuilt
whenever any ES-related XML source files are changed.
Reviewed-by: Chad Versace <chad.versace@linux.intel.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>
This ensures that GLES1-only typedefs are available in these files.
In a future patch, this will allow us to expand the dispatch table to
include GLES1-only functions.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
In commits bad96f6 and e7dd2e5 I added the following aliases:
- ClampColor -> ClampColorARB
- VertexAttribDivisor -> VertexAttribDivisorARB
But I neglected to update check_table.cpp, causing "make check" to
fail for non-shared-glapi builds.
This patch removes the functions that are now aliased from
check_table.cpp, so that "make check" works correctly again.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Previously this function was only implemented for non-shared-glapi
builds. Since the function is only intended for debugging purposes we
use a simple O(n) algorithm.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
There's no reason to have separate slots in the dispatch table for
these two functions, since they are synonymous.
Note: previous to this patch, we never populated the dispatch table
slot for VertexAttribDivisor, which was ok, since it is not required
until 3.3. After this patch, both functions will be usable provided
that the ARB_instanced_arrays extension is present.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There's no reason to have separate slots in the dispatch table for
these two functions, since they are synonymous.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Note that we are missing the ARB_internalformat_query extension, which
provides the glGetInternalformativ function needed by GL ES 3.0.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Note: mapi_abi can consume API information from either XML or a .csv
file. A side effect of this change is that the ES1 and ES2 API
printers can only be used with XML input now. That's ok, since the
.csv input format is only used for the OpenVG API.
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, the ES1, ES2, and shared GLAPI printers passed a list of
function names to the base class constructor, which was used by the
_override_for_api() function to loop over all the API functions and
adjust their 'hidden' and 'handcode' attributes as appropriate for the
API flavour being code-generated.
This patch lifts the loop from _override_for_api() into its caller,
and makes it into a polymorphic function, so that the derived classes
can customize its behaviour directly. In a future patch, this will
allow us to override the 'hidden' and 'handcode' attributes based on
information from the XML rather than a list of functions.
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, _get_api_entries() would make a deep copy of each element
in the entries table before modifying the 'hidden' and 'handcode'
attributes. This was unnecessary, since the entries aren't used again
after this function. Removing the copy simplifies the code, because
it is no longer necessary to adjust the alias pointers to point to the
copied entries.
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Currently mapi_abi.py uses hardcoded lists of function names (in
gles_api.py) to determine which functions need to be included in the
GLES 1 or GLES 2 API. This patch removes a sanity check which
verified that all GLES functions listed in the hardcoded lists were
actually present in the XML.
Later patches in this series will modify mapi_abi.py to determine
which functions need to be included in the GLES 1 or GLES 2 API based
directly on the XML. Once that is done, the sanity check will be
redundant. Removing the sanity check now will simplify the patches to
come.
Tested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.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>
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>
This should be named GL_POLYGON_OFFSET_BIAS_EXT and listed under the
EXT_polygon_offset section. (Solution by Ian Romanick)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Oliver McFadden <oliver.mcfadden@linux.intel.com>
_glapi_table is a struct full of named function pointers, while the generated
code just wants to treat it as an array of function pointers. Cast to avoid
the compiler warning.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
NOTE: This is a candidate for the 9.0 branch
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: Kristian Høgsberg <krh@bitplanet.net>
This fixes an issue where the local 'table' variable was hiding the
function parameter name in glGetColorTable(..., void *table).
This should be OK as long as there's never a GL entrypoint that uses
'disp_table' as a parameter name.
Note: This is a candidate for the 9.0 branch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This patch has been generated by the following Coccinelle semantic
patch:
// Don't cast the return value of malloc/realloc.
//
// Casting the return value of malloc/realloc only stands to hide
// errors.
@@
type T;
expression E1, E2;
@@
- (T)
(
_mesa_align_calloc(E1, E2)
|
_mesa_align_malloc(E1, E2)
|
calloc(E1, E2)
|
malloc(E1)
|
realloc(E1, E2)
)
We were stomping on the caller's buffer by ignoring their alignment
requests and other pixel store modes. This patch makes the USE_XCB path match
the older one more closely.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059
Signed-off-by: Julien Cristau <julien.cristau@logilab.fr>
Signed-off-by: Brian Paul <brianp@vmware.com>
These are largely based on the src/mapi/glapi/tests. However,
shared-glapi provides less external visibility into the dispatch table,
so there is less to test. Also, shared-glapi does not implement
_glapi_get_proc_name, so that test was removed.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
When --enable-shared-glapi is used, all non-ABI entries in the table are
lies. Avoiding the use of glapitable.h avoids the lies. The only
entries used in this code are entries that are ABI. For these, the ABI
offset can be used directly.
Since this code is in src/glx, it can't use src/mesa/main/dispatch.h to
get the pretty names for these offsets.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
When --enable-shared-glapi is used, all non-ABI entries in the table are
lies. There are two completely separate code generation paths used to
assign dispatch offset. Neither has any clue about the other.
Unsurprisingly, the can't agree on what offsets to assign.
This adds a bunch of overhead to __glXNewIndirectAPI, but this function
is called at most once.
The test ExtensionNopDispatch was removed. There was just no way to
make this test work with the information provided in shared-glapi.
Since indirect_glx.c uses _glapi_get_proc_offset now, it was also
impossible to make the tests work without shared-glapi. So much pain.
This fixes indirect rendering with shared-glapi.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
This fixes 'make check' on with --enable-shared-glapi. This test cannot work
in that environment.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
We already provided these files on 'make install', but only created a
'libglapi.so' in the top-level lib/ convenience folder. We used to
create all three, but at some point in the build system churn, it broke.
Various applications (like the ES2 conformance suite) seem to link
against libglapi.so.0, so without these links, setting LD_LIBRARY_PATH
and LIBGL_DRIVERS_PATH can lead to using /usr/lib/libglapi.so.0 with
/home/whatever/libGL.so, which leads to API calls getting routed
incorrectly (i.e. glCompileShader -> _mesa_LinkProgramARB), which leads
to rage problems.
Preserve developer sanity...install links.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
* "configure substitutions are not allowed in _SOURCES variables" in automake,
so remove the AC_SUBST'ed GLAPI_ASM_SOURCES and instead use some AM_CONDITIONALS
to choose which asm sources are used
* Change GLAPI_LIB to point to the .la file in other Makefile.am files, and make a link
to the .a file for the convenience of other Makefiles which have not yet been converted
to automake
v2:
- Use AM_CPPFLAGS for cleaner build output
- EXTRA_SOURCES is not needed
- Remove libglapi.a compatibility link on clean
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Matt Turner <mattst88@gmail.com>
automake doesn't allow hyphens in variable names
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Matt Turner <mattst88@gmail.com>
We don't generate public entrypoints for GLES extensions, so move the
GL_NV_draw_buffers definition from ARB_draw_buffers.xml to es_EXT.xml.
When the extension is defined in ARB_draw_buffers.xml, we end up with a
public entry point for it, but no prototype, which gives an error when
compiled with --disable-asm and --disable-shared-glapi.
Instead, just move the GLES extension to es_EXT.xml so this doesn't happen.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Redo this commit, and remove the inclusion of gl2ext.h
from src/mapi/glapi/glapi_priv.h. The include was added in
8f3be33985 to fix a missing prototype for
glDrawBuffersNV and others, but it's not possible to include both
glext.h and gl2ext.h from the same file.
I don't see the missing prototype here (with or without shared glapi)
so I'm just removing the offending #include.
Also, since we're redoing this, update to the most recent gl2ext.2.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Add "-f $(srcdir)/gl_API.xml" to the arguments of all
the scripts that by default look for gl_API.xml in the
working directory when run with no arguments, and prepend
$(srcdir) to those scripts that are already using an
explicit -f argument.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For some reason regular gcc on Linux didn't catch these but the mingw
compiler did (generated errors, not warnings).
v2: include the changes in src/mapi/ too
Fixes the es2 build with gcc.
Note: in glext.h the prototypes for glShaderSource() and glShaderSourceARB()
disagree: only the former has the extra const qualifier.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
v2: Fix a typo spotted by Eric Anholt.
v3: Fix missing "GL" on types, fix style, fix Studly_Caps extension name,
drop commented code duplicated with GL3x.xml [anholt]
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This lets us select the front buffer for reading under GLES2.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch updates .gitignore files to account for the new build
artifacts introduced by the following commits:
ae376f0 glx/tests: Rename test as glx-test
8fecdcc mesa/tests: Add tests for _mesa_lookup_enum_by_{name,nr} functions
a29ad2b mesa/tests: Add tests for the generated dispatch table
There is no GLX protocol for these functions. Open-source Linux
driver have not supported this extension for many years, and it seems
unlikely at this point that this support will return. There's no
reason to have slots for these functions in the dispatch table.
The unit tests (GetProcAddress::TableDidntShrink and others) are also updated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is no GLX protocol for these functions. No open-source Linux
driver has ever supported this extension, and it seems unlikely at
this point that one ever will. There's no reason to have slots for
these functions in the dispatch table.
The unit tests (GetProcAddress::TableDidntShrink and others) are also updated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is no GLX protocol for these functions. No open-source Linux
driver has ever supported this extension, and it seems unlikely at
this point that one ever will. There's no reason to have slots for
these functions in the dispatch table.
The unit tests (GetProcAddress::TableDidntShrink and others) are also updated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is no GLX protocol for these functions, and no Linux driver has
ever supported this extension. There's no reason to have slots for
these functions in the dispatch table.
The unit tests (GetProcAddress::TableDidntShrink and others) are also updated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is no GLX protocol for this function. Open-source Linux driver
have not supported this extension for many years, and it seems
unlikely at this point that this support will return. There's no
reason to have slots for this function in the dispatch table.
The unit tests (GetProcAddress::TableDidntShrink and others) are also updated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There is no GLX protocol for these functions, and no Linux driver has
ever supported this extension. There's no reason to have slots for
these functions in the dispatch table.
The unit tests (GetProcAddress::TableDidntShrink and others) are also updated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
These are from OpenGL 3.1 and ARB_uniform_buffer_object. I only added
them to 3.1 because that required the least work.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
These are from OpenGL 3.3, ARB_texture_swizzle, and
EXT_texture_swizzle (with different names). I only added them to 3.3
because that required the least work.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
I tried to update all the old Makefiles that included the default
config to be sure they had a default target if they didn't previously
have one, since this new all target will always point at it. Almost
everything had one.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
remove archaic .cvsignore
*.pyo is already in toplevel .gitignore
*.pyc is already in toplevel .gitignore
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This variable won't be set when called from non-automake makefiles,
but it cleans up shared-glapi's output.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Mesa already always depends on python to build. The checked in
changes are not reviewed (because any trivial change rewrites the
world). We also have been pushing commits between xml change and
regen where at-build-time xml-generated code disagrees with committed
xml-generated code. And worst of all, sometimes we ("I") check in
*stale* xml-generated code.
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
The __glapi_gentable_set_remaining_noop() routine treats the _glapi_struct
as an array of _glapi_get_dispatch_table_size() pointers, so we have to
allocate _glapi_get_dispatch_table_size()*sizeof(void*) bytes rather
than sizeof(struct _glapi_struct) bytes.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
The Android build was broken by
commit ca760181b4
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Fri Mar 16 12:55:40 2012 -0400
shared-glapi: Convert to automake
The offending change was that it redefined the filepaths in sources.mak
like this:
- FOO_FILES := bar.c
+ FOO_FILES := $(TOP)/src/mapi/mapi/bar.c
This broke the build because source filepaths in Android makefiles must be
relative to the makefile.
Ideally, this could be fixed by reverting the change in sources.mak and
making shared-glapi's Makefile.am use $(addprefix $(TOP)/src/mapi/mapi,
$(FOO_FILES)). However, automake doesn't understand builtin GNU make
functions, such as addprefix. So, it seems that automake and Android can
no longer share sources.mak.
Fix the build by duplicating the source lists from sources.mak into
Android.mk.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This is set correctly in gl.spec, but was missed in Mesa. As a
result, only one of the two was hooked up in Mesa.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Noticed this was missing when writing the "glapi: sort ARB extensions
by number" commit, which at least shows it was effective.
Reviewed-by: Brian Paul <brianp@vmware.com>
Noticed it was missing based on the lack of a descriptive enum
name from this bug's error message:
https://bugs.freedesktop.org/show_bug.cgi?id=44039
This moves two enums out of GL3x.xml. Though since this and
GL_ARB_texture_compression_rgtc are both strict subsets of GL3,
both extensions should have had all their enums in that file
to begin with, not just two of them.
Reviewed-by: Brian Paul <brianp@vmware.com>
And add comments to fill in for extensions that aren't there.
Noticed the comment about "ARB extensions sorted by extension number"
didn't extend to the <xi:include> directives when it became clear
GL_ARB_texture_rg was missing, going by the error message seen here:
https://bugs.freedesktop.org/show_bug.cgi?id=44039
This makes it easier to notice in the future if an extension is missing
when it shouldn't be.
Reviewed-by: Brian Paul <brianp@vmware.com>
This adds the xml file covering ARB_blend_func_extended.
v2: fix SRC1_ALPHA
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use -no-undefined to assure libtool that the library has no unresolved
symbols at link time, so that libtool will build a shared library on
platforms that require that all symbols are resolved when the library
is linked.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
This fixes a build problem where EGL links to libgbm.la, which encodes
a relative path to it's libglapi.so dependency. The relative path
breaks when the linker tries to resolve it from src/egl/main instead
of src/gbm. Typically we silently fall back to the system
libglapi.so, which is wrong and breaks when there isn't one.
Morale of the story: don't mix mklib and libtool.
This patch allows the Mac OS X SCons build to complete. The assembly
sources contain psuedo-ops that not are supported on Mac OS X.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
From http://www.opengl.org/registry/specs/ARB/seamless_cube_map.txt:
Accepted by the <cap> parameter of Enable, Disable and IsEnabled,
and by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv
and GetDoublev:
TEXTURE_CUBE_MAP_SEAMLESS 0x884F
This caused a change in enums.c, which is manually built from the .xml
files.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This fixes build errors like
In file included from glapi_dispatch.c:91:
../../../src/mapi/glapi/glapitemp.h:4641: error: no previous prototype for
'glDrawBuffersNV'
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Lucas Stach <dev@lynxeye.de>
When GLAPIENTRY is __stdcall (ie Windows), the stack is popped by the
callee making the number/type of arguments significant, therefore
using a generic no-op causes stack corruption for many entry-points.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
-fvisibility=hidden was preventing them from being exported, which
combined with shared-glapi was causing undefined symbol errors at
runtime.
We don't want to make these functions part of the ABI, and given
how simple they are, we simply inline them.
libglapi.so, libGL.so, libGLESv2.so, libGLESv1_CM.so must all
come from the same version of Mesa or bad things may happen.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Matt Turner <mattst88@gmail.com>
The versions in the xserver and in libGL have diverged enough that the
xserver doesn't want these.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glext.h doesn't have GL_MIN_PROGRAM_TEXEL_OFFSET_EXT or
GL_MAX_PROGRAM_TEXEL_OFFSET_EXT. Using them in the XML causes code to
be generated for the xserver that won't compile. Use the names that
exist instead.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
That file was removed from the xserver with commit:
commit a80780a7638f847c3be20e5e0c7fe85e83d9bdd1
Author: Adam Jackson <ajax@redhat.com>
Date: Wed Nov 17 09:03:06 2010 -0500
glx: Remove swap barrier and hyperpipe support
Never implemented in any open source driver. The implementation
assumed explicit DDX driver knowledge of how the client-side driver
worked, since at the time the server's GL renderer was not a DRI driver.
But now, it is, so any implementation of these should be done with
additional DRI driver API, like the swap control extension.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This also moves ATI_draw_buffers. This is to facilitate enabling
NV_draw_buffers in OpenGL ES 2.0.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
All of the extensions actually supported by Mesa have been remapped by
remap.c for a long time. Emitting all of these data structures is
just clutter.
Drivers that need additional functions remapped, should add
'offset="assign"' to the function definition in the .xml file.
The changes to remap_helper.h are in a follow-on ~8700 line patch that
would surely be rejected by the mailing list.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
These are the new API entrypoints for ARB_vertex_type_2_10_10_10_rev
extension, along with the new INT_2_10_10_10_REV enum.
v2: fixup crazy whitespace cut-n-paste mess
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
When generating dispatch templates, emit the '(void) blah;' magic to
make GCC happy. This reduces a lot of warning spam if you build with
-Wunused-parameter or -Wextra.
Reviewed-by: Chia-I Wu <olv@lunarg.com>
Acked-by: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Marek Olšák <maraeo@gmail.com>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Acked-by: Jakob Bornecrantz <jakob@vmware.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Build-Tested-by: Jakob Bornecrantz <jakob@vmware.com>
Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Compiling some (large) files with i686-pc-mingw32-gcc 4.2.2 (at least)
and the -gstabs option triggers a compiler error. Use this work-around
to simply compile the effected files without -gstabs.
Commit 6eff33dc (glapi: generate ES dispatch headers from core mesa)
replaced the autogenerated files
src/mapi/es1api/main/{dispatch,remap_helper}.h with new autogenerated
files src/mesa/main/api_exec_es{1,2}_{dispatch,remap_helper}.h. This
patch updates the .gitignore files to properly ignore the new
autogenerated files, and stop ignoring the old autogenerated files.
Reviewed-by: Chia-I Wu <olv@lunarg.com>
GLESv1 and GLESv2 have their own dispatch.h and remap_helper.h. These
headers are only used by api_exec_es1.c and api_exec_es2.c in core mesa.
Move the rules to generate them from glapi to core mesa.
Reviewed-by: Brian Paul <brianp@vmware.com>
[olv: updated after reviewing to fix SCons build]
glapi_gen.mk is supposed to be included by glapi users to simplify
header generation. This commit also makes es1api, es2api, and
shared-glapi use it.
Reviewed-by: Brian Paul <brianp@vmware.com>
[olv: updated after reviewing to prefix all variables in glapi_gen.mk by
glapi_gen]
glapi/gen-es/ defines two sets of GLAPI XMLs for OpenGL ES 1.1
(es1_API.xml) and 2.0 (es2_API.xml) respectively. They are used to
generate dispatch.h and remap_helper.h for GLES. Together with
gl_and_es_API.xml, we have to maintain three sets of GLAPI XMLs.
This commit makes dispatch.h and remap_helper.h for GLES be generated
from gl_and_es_API.xml.
Reviewed-by: Brian Paul <brianp@vmware.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>
Move the list of entry points belong to GLES from mapi_abi.py to a new
file.
Until we figure out how to describe the APIs an entry point belongs to
in the XML file, and how to handle the case where an entry point others
alias is missing in some APIs, this is an easier solution than
maintaining another two sets of XMLs in glapi/gen-es/.
Reviewed-by: Brian Paul <brianp@vmware.com>
FramebufferTextureLayer is an alias of FramebufferTextureLayerEXT, so
FramebufferTextureLayerARB needs to be listed as an alias of
FramebufferTextureLayerEXT rather than FramebufferTextureLayer.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
This change to _glapi_create_table_from_handle causes it to fill the dispatch
table with NoOps for unimplemented functionality. This matches what is done
in indirect_init.c and also allows us to enable logging (when built with
-DDEBUG and the MESA_DEBUG or LIBGL_DEBUG environment variables are set) to
catch cases where clients are trying to use these unimplemented extentions.
Additionally, this fixes some gcc -pedantic warnings.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
x86_64_entry_start needs to be declared static in the C code,
in order to have the correct address in entry_get_public
(seems not to be needed on x86).
The compiler needs to lookup a local not a global object.
Otherwise addresses needed for _glapi_proc_address will be computed
from some random offset (0x6400229a61058b48 in my case).
glapidispatch.h was located in glapi and shared with mesa core. Because
the way it was shared, mesa core must include it indirectly via
main/dispatch.h.
Now that it is no longer needed by glapi and is located in core mesa,
merging it with main/dispatch.h to avoid wrong uses.
Generate different glapidispatch.h's for GL and GLES. For GLES, we want
a local remap table.
This reverts commit 5af46e8360. The
commit will break GL remap table setup when main/glapidispatch.h is
regenerated.
glx code hasn't lived under xserver/GL for a long time now.
Signed-off-by: Nathan Kidd <nkidd@opentext.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
Since the SET_xxx and GET_xxx macros used to initialize the remap_table
have been replaced by inline functions, the missing late macro expansion
leads to driDispatchRemapTable not being redefined to remap_table, which
in turn causes the remap_table not to be setup properly.
This commit fixes the issue by moving the table redefinition after the
definition of driDispatchRemapTable but in front of the inline function
definitions.
Squashed commit of the following:
Author: Marek Olšák <maraeo@gmail.com>
mesa: fix getteximage so that it doesn't clamp values
mesa: update the compute_version function
mesa: add display list support for ARB_color_buffer_float
mesa: fix glGet query with GL_ALPHA_TEST_REF and ARB_color_buffer_float
commit b2f6ddf907935b2594d2831ddab38cf57a1729ce
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Tue Aug 31 16:50:57 2010 +0200
mesa: document known possible deviations from ARB_color_buffer_float
commit 5458935be800c1b19d1c9d1569dc4fa30a97e8b8
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Tue Aug 24 21:54:56 2010 +0200
mesa: expose GL_ARB_color_buffer_float
commit aef5c3c6be6edd076e955e37c80905bc447f8a82
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Thu Aug 26 18:12:34 2010 +0200
mesa, mesa/st: handle read color clamping properly
(I'll squash the st/mesa part to a separate commit. -Marek)
We set IMAGE_CLAMP_BIT in the caller based on _ClampReadColor, where
the operation mandates it.
TODO: did I get the set of operations mandating it right?
commit 3a9cb5e59b676b6148c50907ce6eef5441677e36
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Thu Aug 26 18:09:41 2010 +0200
mesa: respect color clamping in texenv programs (v2)
Changes in v2:
- Fix attributes other than vertex color sometimes getting clamped
commit de26f9e47e886e176aab6e5a2c3d4481efb64362
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Thu Aug 26 18:05:53 2010 +0200
mesa: restore color clamps on glPopAttrib
commit a55ac3c300c189616627c05d924c40a8b55bfafa
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Thu Aug 26 18:04:26 2010 +0200
mesa: clamp color queries if and only if fragment clamping is enabled
commit 9940a3e31c2fb76cc3d28b15ea78dde369825107
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Wed Aug 25 00:00:16 2010 +0200
mesa: introduce derived _ClampXxxColor state resolving FIXED_ONLY
To do this, we make ClampColor call FLUSH_VERTICES with the appropriate
_NEW flag.
We introduce _NEW_FRAG_CLAMP since fragment clamping has wide-ranging
effects, despite being in the Color attrib group.
This may be easily changed by s/_NEW_FRAG_CLAMP/_NEW_COLOR/g
commit 6244c446e3beed5473b4e811d10787e4019f59d6
Author: Luca Barbieri <luca@luca-barbieri.com>
Date: Thu Aug 26 17:58:24 2010 +0200
mesa: add unclamped color parameters
makedepend would crash when a source includes a header indirectly, such
as
#define HEADER "some-header.h"
#include HEADER
Do not define HEADER (makedepend would detects this as an incomplete
include) and add the dependency manually in the Makefile.
This should hopefully fix bug #33374.
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
libraries will be created. They are libGLESv1_CM, libGLESv2, and
libglapi. Last, libGL or opengl32 will link to libglapi. This change
is required as _glapi_* will be declared as __declspec(dllimport) in
libmesa.a on windows. libmesa.a expects those symbols to be defined in
another DLL. Due to this change to GL, GLES support is marked
experimental.
Note that GLES requires libxml2-python to generate some of its sources.
When --enable-shared-glapi is specified, libGL will share libglapi with
OpenGL ES instead of defining its own copy of glapi. This makes sure an
app will get only one copy of glapi in its address space.
The new option is disabled by default. When enabled, libGL and libglapi
must be built from the same source tree and distributed together. This
requirement comes from the fact that the dispatch offsets used by these
libraries are re-assigned whenever GLAPI XMLs are changed.
For GLX, indirect rendering for has_different_protocol() functions is
tricky. A has_different_protocol() function is assigned only one
dispatch offset, yet each entry point needs a different protocol opcode.
It cannot be supported by the shared glapi. The fix to this is to make
glXGetProcAddress handle such functions specially before calling
_glapi_get_proc_address.
Note that these files are automatically generated/re-generated
src/glx/indirect.c
src/glx/indirect.h
src/mapi/glapi/glapi_mapi_tmp.h
Move _glapi_* symbols from libGLESv1_CM.so and libGLESv2.so to
libglapi.so. This makes sure an app will get only one copy of glapi in
its address space.
Note that with this change, libGLES* and libglapi must be built from the
same source tree and distributed together. This requirement comes from
the fact that the dispatch offsets used by these libraries are
re-assigned whenever GLAPI XMLs are changed.
In bridge mode, mapi no longer implements glapi.h. It becomes a user of
glapi.h. Imagine an app that uses both libGL.so and libGLESv2.so.
There will be two copies of glapi in the app's memory. It is possible
that _glapi_get_dispatch does not return what _glapi_set_dispatch set,
if they access different copies of the global variables. The solution
to this situation to build either one of the libraries as a bridge to
the other. Or build both libraries as bridges to another shared
glapi library.
When MAPI_MODE_GLAPI is defined, u_current_table is renamed to
_glapi_Dispatch or _glapi_tls_Dispatch. The ASM dispatchers should not
use hardcoded name.
The new implementation is based on mapi. No new script is needed. As
noted in sources.mk, the way to use it is to compile MAPI_GLAPI_SOURCES
with MAPI_MODE_GLAPI defined.
Fix GLAPIPrinter, ES1APIPrinter, and ES2APIPrinter to output files that
are ready for compilation. Since gl_and_es_API.xml is based on
gl_API.xml, the hidden and handcode attributes of entries have to be
overridden for ES1APIPrinter and ES2APIPrinter.
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.
Update SConscripts to re-enable or add support for EGL on windows and
x11 platforms respectively. targets/egl-gdi is replaced by
targets/egl-static, where "-static" means pipe drivers and state
trackers are linked to statically by egl_gallium, and egl_gallium is a
built-in driver of libEGL. There is no more egl_gallium.dll on Windows.
Given a dispatch slot, entry_get_public returns the address of the
corresponding public entry point. There may be more than one of them.
But since they are all equivalent, it is fine to return any one of them.
With entry_get_public, the address of any public entry point can be
calculated at runtime when an assembly dispatcher is used. There is no
need to have a mapping table in such case. This omits the unnecessary
relocations from the binary.
Hidden entries are just like normal entries except that they are not
exported. Since it is not always possible to hide them, and two hidden
aliases can share the same entry, the name of hidden aliases are mangled
to '_dispatch_stub_<slot>'.
Split out function name generation from _c_decl to _c_function, and use
it everywhere. Add an optional 'export' argument to _cdecl. It is
prepended to the returned string.
Rename MAPI_GLAPI_SOURCES to MAPI_UTIL_SOURCES. Rename macro
MAPI_GLAPI_CURRENT to MAPI_MODE_UTIL. Update the comments to make it
clear that mapi may be used in two ways and how.
The preprocessor magic in mapi was nothing but obfuscation. Rewrite
mapi_abi.py to generate real C code.
This commit removes the hack added in
43121f2086.
Fixes nasty bug where some parts of the code didn't define WIN32_THREADS
and were using the integer mutex implementation, causing even confusion
to the debuggers.
And there is little interest of other thread implemenation on Win32
besides Win32 threads.
This code was for the old GLcore build of the software rasteriser. The
X server switched to a DRI driver for software indirect GLX long ago.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Use scons target and dependency system instead of ad-hoc options.
Now is simply a matter of naming what to build. For example:
scons libgl-xlib
scons libgl-gdi
scons graw-progs
scons llvmpipe
and so on. And there is also the possibility of scepcified subdirs, e.g.
scons src/gallium/drivers
If nothing is specified then everything will be build.
There might be some rough corners over the next days. Please bare with me.
Move defines in glapioffsets.h to glapidispatch.h. Rename
_gloffset_FIRST_DYNAMIC to _gloffset_COUNT, which is equal to the number
of entries in _glapi_table.
Consistently use SET_by_offset, GET_by_offset, CALL_by_offset, and
_gloffset_* to recursively define all SET/GET/CALL macros.
glapioffsets.h exists for the same reason as glapidispatch.h does. It
is of no use to glapi. This commit also drops the use of glapioffsets.h
in glx as glx is considered an extension to glapi when it comes to
defining public GL entries.
glapidispatch.h exists so that core mesa (libmesa.a) can be built for
DRI drivers or for non-DRI drivers as a compile time decision (whether
IN_DRI_DRIVER is defined). It is of no use to glapi. This commit also
drops the use of glapidispatch.h in glx and libgl-xlib as they are
considered extensions to glapi when it comes to defining public GL
entries.
A number of other files had to be updated as well because const
qualifiers were added to the glMultiDrawArrays() function.
Also, GL_FIXED is now defined in glext.h.
This reverts commit b9abc6139a and the
follow on fixes (7aae704 and 6fe1b47). It's changing the glapi/driver
ABI and causes a number of problems for debug/non-debug builds.
There's a useful feature buried in glapi to log all API calls to stderr.
Unfortunately it requires editing the code and then it's enabled
unconditionally for that build. This patch builds in API logging for
debug builds and makes it run-time switchable by setting MESA_DEBUG=dispatch.
That is, replace the old _glapi_* names by new names that start with
u_current_. When MAPI_GLAPI_CURRENT is defined, u_current.h defines
rename macros to restore the old names. That is done for ABI
compatibility.
glapi defines an interface that is used by DRI drivers. It must not be
changed in an ABI incompatible way. This commit moves all
functions/variables belong to the interface to glapi.h. Instead of
including u_current.h from glapi.h, u_current.h now includes glapi.h.
Specifically, move all or most of
glapi/glapi.c to mapi/u_current.c,
glapi/glapi_execmem.c to mapi/u_execmem.c,
glapi/glthread.[ch] to mapi/u_thread.[ch]
and remove their dependencies on core Mesa headers.