| The State Machine Model |
Glide is state based: rendering “modes” can be set once and then remain in effect until reset. Parameter values like a reference value for depth comparisons and a specific depth test are set once and will be used whenever depth testing is enabled (until they are given new values).The state machine model allows users to set modes and reference values only when they change, minimizing the host-to-hardware transfers.
For example, one of the state variables Glide maintains is the “current mipmap”, used during texture mapping.
| Definition:mipmap |
| A mipmap is a collection of hierarchically defined texture maps that are loaded into the texture memory that supports the TMU's. A stateless model would not retain information about the contents of the texture memory, so each rendering operation would have to include a texture memory address. |
Sending redundant state information can lead to noticeable performance degradation. For example, if a system is attempting to render 200,000 triangles per second and the “current mipmap” is sent as a 4-byte address, bandwidth associated with updating this single state variable can amount to 800KB/sec. Compound this with all of the other state information necessary and the amount of unnecessary data sent across the system bus can become overwhelming.Two library functions are used to save and restore state.
void grGlideGetState( GrState *state ) void grGlideSetState( const GrState *state )
grGlideGetState() makes a copy of the current state of the current Voodoo Graphics subsystem in a GrState structure state provided by the user. The saved state can be restored at some later time with grGlideSetState(). These routines save and restore all Glide state, and therefore are expensive to use.
NOTE:
If only a small subset of Glide state needs to be saved and restored, these routines should not be used.