[Mesa-dev] [PATCH 1/4] mesa/vbo: remove redundant _mesa_is_bufferobj() calls
Brian Paul
brianp at vmware.com
Thu Mar 30 16:32:30 UTC 2017
On 03/30/2017 05:26 AM, Timothy Arceri wrote:
> This is already called inside the vbo_exec_vtx_{unmap,map}()
> functions.
> ---
> src/mesa/vbo/vbo_exec_draw.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
> index c2fcb66..7e538c3 100644
> --- a/src/mesa/vbo/vbo_exec_draw.c
> +++ b/src/mesa/vbo/vbo_exec_draw.c
> @@ -419,50 +419,45 @@ vbo_exec_vtx_flush(struct vbo_exec_context *exec, GLboolean keepUnmapped)
> struct gl_context *ctx = exec->ctx;
>
> /* Before the update_state() as this may raise _NEW_VARYING_VP_INPUTS
> * from _mesa_set_varying_vp_inputs().
> */
> vbo_exec_bind_arrays( ctx );
>
> if (ctx->NewState)
> _mesa_update_state( ctx );
>
> - if (_mesa_is_bufferobj(exec->vtx.bufferobj)) {
> - vbo_exec_vtx_unmap( exec );
> - }
> + vbo_exec_vtx_unmap(exec);
>
> if (0)
> printf("%s %d %d\n", __func__, exec->vtx.prim_count,
> exec->vtx.vert_count);
>
> vbo_context(ctx)->draw_prims( ctx,
> exec->vtx.prim,
> exec->vtx.prim_count,
> NULL,
> GL_TRUE,
> 0,
> exec->vtx.vert_count - 1,
> NULL, 0, NULL);
>
> /* If using a real VBO, get new storage -- unless asked not to.
> */
> - if (_mesa_is_bufferobj(exec->vtx.bufferobj) && !keepUnmapped) {
> + if (!keepUnmapped)
> vbo_exec_vtx_map( exec );
> - }
The comment doesn't quite agree with the new conditional now. I guess
you could strike the "If using a real VBO" part.
> }
> }
>
> /* May have to unmap explicitly if we didn't draw:
> */
> - if (keepUnmapped &&
> - _mesa_is_bufferobj(exec->vtx.bufferobj) &&
> - exec->vtx.buffer_map) {
> + if (keepUnmapped && exec->vtx.buffer_map) {
> vbo_exec_vtx_unmap( exec );
> }
>
> if (keepUnmapped || exec->vtx.vertex_size == 0)
> exec->vtx.max_vert = 0;
> else
> exec->vtx.max_vert = vbo_compute_max_verts(exec);
>
> exec->vtx.buffer_ptr = exec->vtx.buffer_map;
> exec->vtx.prim_count = 0;
>
Reviewed-by: Brian Paul <brianp at vmware.com>
More information about the mesa-dev
mailing list