| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@freedesktop.org>
|
|
This is made possible by making glapioffsets.h and glapidispatch.h
internal headers of glapi. They should only be included indirectly
through dispatch.h by mesa.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
|
|
This trims down and cleans up imports.h and glheader.h quite a bit.
|
|
This is another step toward removing a whole bunch of -I flags from
the cc commands. Still need to address driver code...
|
|
generated file, called src/mesa/glapi/dispatch.h, is added. This file
contains three macros for each API function. It contains a GET, a SET, and
a CALL. Each of the macros take a pointer to the context and a pointer to
the dispatch table.
In several threads on mesa3d-dev we discussed replacing _glapi_add_entrypoint
with a new function called _glapi_add_dispatch. For this discussion, the
important difference between the two is that the caller of _glapi_add_dispatch
does *not* know what the dispatch offset will be at compile time. Because of
this callers need to track the dispatch offset returned by
_glapi_add_dispatch.
http://marc.theaimsgroup.com/?t=111947074700001&r=1&w=2
The downside is that driver code then has to access the dispatch table two
different ways. It accesses it using structure tags (e.g., exec->Begin) for
functions with fixed offsets and via a remap table (e.g., exec[
remap->NewExtensionFunction ]) for functions without fixed offsets. Yuck!
Using the macros allows both types of functions to be accessed
identically. If a driver needs to set a pointer for Begin, it does
'SET_Begin(ctx, exec, my_begin_function)'. If it needs to set a pointer
for NewExtensionFunction, it does 'SET_NewExtensionFunction(ctx, exec,
my_NewExtensionFunction_function)'. Furthermore, if at some point in
the future a static offset is assigned for NewExtensionFunction, only
the macros need to change (instead of every single place that accesses a
table for that function).
This code differs slightly from the originally posted patches in that the
CALL, GET, and SET marcos no longer take a context pointer as a parameter.
Brian Paul had suggested that the remap table could be stored as a global
since it would be set at CreateScreen time and would be constant for all
contexts. This change reflects that feedback.
http://marc.theaimsgroup.com/?t=112087194700001&r=1&w=2
|
|
is basically patch #2939 from X.org bugzilla #3379. This does *not*
fix the bug as it does not dynamically generate stubs at run-time. It
just gets things one step closer.
|
|
libGL builds.
|
|
|
|
|
|
|
|
points so that the calling conventions will work correctly with the assembler
stubs with the Open Watcom compiler.
|
|
|
|
|
|
1. Remove all.h and PC_HEADER junk.
2. Rolled mem.c and mem.h into imports.c and imports.h
3. Include imports.h instead of mem.h
Restore _mesa_create/initialize_context() to be like they were in 4.0.4
New wrappers for a few std C functions: _mesa_atoi(), _mesa_strstr(), etc.
|
|
Instead of mstdio.[ch], use imports.[ch] to isolate these functions.
|
|
|
|
|
|
|
|
|
|
Folded glapinoop.c code into glapi.c.
Added code to glapitemp.h to fill in dispatch tables.
Updated Makefiles.
|
|
|
|
|
|
that used to require a 'ReducedPrimitiveChange' callback.
Various compilation fixes for XFree86.
Reverted to the older version of glcore.h used internally in XFree86, and
moved it to 'Mesa/include/GL/internal/glcore.h', for compatibility with
XFree86.
|
|
Modified Files:
Mesa/demos/descrip.mms Mesa/src/descrip.mms
Mesa/src/dispatch.c
-Updated VMS compile suppport
-Included glthread.h in dispatch.c to make sure that THREADS is defined if
i.e. PTHREADS is defined in the makefile.
----------------------------------------------------------------------
|
|
New array_cache module
Support 8 texture units in core mesa (now support 8 everywhere)
Rework core mesa statechange operations to avoid flushing on many
noop statechanges.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
