On Thu, May 27, 2004 at 05:55:29PM -0700, Jon Smirl wrote: | ... What does this dispatch dispatch to?
In most implementations, a dynamically-generated stub that jumps through a known offset in a vector of function pointers. That entry in the vector might not exist, or might be null, if the rendering context that's current at the time doesn't support the associated extension.
I want to expand on that a little.
The dispatch table is how you get around the fact that the function-pointers and the static functions (i.e., directly calling glVertex3f) are context independent. All of the real magic obviously happens in the driver, so we need to get from the context-independent code to the context-dependent code ASAP.
Each context has an associated dispatch table. There is an entry in this table for every gl* function. If you look in src/mesa/glapi/glapitable.h you'll see the structure that defines the table. This is analogous to the virtual function table associated with an object in C++. Ignoring multithreading, when you make a context current, a pointer to its dispatch table is stored in the global variable _glapi_Dispatch.
When a GL function is called, it gets the current dispatch pointer and calls the function pointed to in the table. Look in src/mesa/glapi/glapitemp.c and src/mesa/main/dispatch.c to see how the default static dispatch functions get generated. There's obviously some overhead, so there are assembly versions that are much faster. See src/mesa/x86/glapi_x86.S and src/mesa/sparc/glapi_sparc.S.
There is another nice side-effect of doing it this way. Since the dispatch table is context dependent, the driver can make it state dependent as well. For example, when we start compiling a display list, we switch to a new dispatch table that contains special versions of all the functions for compiling display lists. That's also how the vertex codegen in the radeon and r200 driver work. At glBegin, the driver analyzes the current state and puts pointers to specialized functions in the dispatch table for glVertex3f, glNormal3f, etc.
There's another neat optimization that Mesa doesn't do, but most "commercial" drivers do. Notice how some functions can't be called between Begin/End and some can't be called outside Begin/End? Instead of testing "Am I inside Begin/End?" in each of those functions, just put a pointer to an error function in the dispatch table when you're in the "wrong" state. I think the right way to do this is to have two tables: an "inside" table and an "outside" table. I think this isn't done in Mesa because it would complicate the display list code.
So, I guess I expanded on it more than a little. :)
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
