summaryrefslogtreecommitdiffstats
path: root/src/mesa/vbo/vbo_exec_api.c
diff options
context:
space:
mode:
authorChad Versace <[email protected]>2011-09-28 17:06:35 -0700
committerChad Versace <[email protected]>2011-10-18 11:42:53 -0700
commitfd7c46f53f3a7ae5c67f3c44ba283eeb4f72b366 (patch)
tree66d5389cde9c5bd181489afde376aee453c07747 /src/mesa/vbo/vbo_exec_api.c
parent4b6311978f6710cfb2e9d77a2ca7a30f709c1f37 (diff)
mesa: Add dd_function_table::PrepareExecBegin
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 <[email protected]> Signed-off-by: Chad Versace <[email protected]>
Diffstat (limited to 'src/mesa/vbo/vbo_exec_api.c')
-rw-r--r--src/mesa/vbo/vbo_exec_api.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index 150589bec5e..5f3ed9d5db4 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -570,6 +570,9 @@ static void GLAPIENTRY vbo_exec_Begin( GLenum mode )
return;
}
+ if (ctx->Driver.PrepareExecBegin)
+ ctx->Driver.PrepareExecBegin(ctx);
+
if (ctx->NewState) {
_mesa_update_state( ctx );