Wrap every place that accesses a dispatch table with a macro. A new script-
authorIan Romanick <idr@us.ibm.com>
Mon, 18 Jul 2005 12:31:24 +0000 (12:31 +0000)
committerIan Romanick <idr@us.ibm.com>
Mon, 18 Jul 2005 12:31:24 +0000 (12:31 +0000)
commit9bdfee3a470a535ebe31074651fbacf680bcea6a
treefba4d709fc92d1afafdf77f0e9db9a82e1d52831
parente0e993c5ff090058037875642dcd34727a3d8760
Wrap every place that accesses a dispatch table with a macro.  A new script-
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
24 files changed:
src/mesa/drivers/dri/ffb/ffb_vtxfmt.c
src/mesa/drivers/dri/r200/r200_vtxfmt.c
src/mesa/drivers/dri/r200/r200_vtxfmt_c.c
src/mesa/drivers/dri/radeon/radeon_vtxfmt.c
src/mesa/drivers/dri/radeon/radeon_vtxfmt_c.c
src/mesa/glapi/Makefile
src/mesa/glapi/gl_table.py
src/mesa/glapi/glthread.h
src/mesa/main/api_arrayelt.c
src/mesa/main/api_loopback.c
src/mesa/main/api_noop.c
src/mesa/main/dispatch.c
src/mesa/main/dlist.c
src/mesa/main/state.c
src/mesa/main/varray.c
src/mesa/main/vtxfmt.c
src/mesa/main/vtxfmt_tmp.h
src/mesa/shader/arbprogparse.c
src/mesa/tnl/t_array_api.c
src/mesa/tnl/t_save_api.c
src/mesa/tnl/t_save_loopback.c
src/mesa/tnl/t_vtx_api.c
src/mesa/tnl/t_vtx_eval.c
src/mesa/tnl_dd/imm/t_dd_imm_capi.h