This hook allows the driver to prepare for a glBegin/glEnd.
i965 will use the hook to avoid avoid recursive calls to FLUSH_VERTICES
during a buffer resolve meta-op.
Detailed Justification
----------------------
When vertices are queued during a glBegin/glEnd block, those vertices must
of course be drawn before any rendering state changes. To enusure this,
Mesa calls FLUSH_VERTICES as a prehook to such state changes. Therefore,
FLUSH_VERTICES itself cannot change rendering state without falling into
a recursive trap.
This precludes meta-ops, namely i965 buffer resolves, from occuring while
any vertices are queued. To avoid that situation, i965 must satisfy the
following condition: that it queues no vertex if a buffer needs resolving.
To satisfy this, i965 will use the PrepareExecBegin hook to resolve all
buffers on entering a glBegin/glEnd block.
--------
v2: Don't add dd_function_table::CleanupExecEnd. Anholt and I discovered
that hook to be unnecessary.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Chad Versace <chad@chad-versace.us>
driver->ProgramStringNotify = _tnl_program_string;
driver->FlushVertices = NULL;
driver->SaveFlushVertices = NULL;
+ driver->PrepareExecBegin = NULL;
driver->NotifySaveBegin = NULL;
driver->LightingSpaceChange = NULL;
void (*FlushVertices)( struct gl_context *ctx, GLuint flags );
void (*SaveFlushVertices)( struct gl_context *ctx );
+ /**
+ * \brief Hook for drivers to prepare for a glBegin/glEnd block
+ *
+ * This hook is called in vbo_exec_Begin() before any action, including
+ * state updates, occurs.
+ */
+ void (*PrepareExecBegin)( struct gl_context *ctx );
+
/**
* Give the driver the opportunity to hook in its own vtxfmt for
* compiling optimized display lists. This is called on each valid
return;
}
+ if (ctx->Driver.PrepareExecBegin)
+ ctx->Driver.PrepareExecBegin(ctx);
+
if (ctx->NewState) {
_mesa_update_state( ctx );