Mesa's implementation of glBindBuffer() checks to see if the supplied buffer name happens to be already bound. If so, it returns immediately, skipping the hash table lookup (mapping the GLuint buffer handle to the actual struct), the associated locking, and reference counting.
Glamor uses a single VBO for everything - operations reserve space in the VBO via glamor_get_vbo_space(); if it fills up, we replace it with a fresh buffer (which is then used for everything). Ideally, Glamor would almost always hit the above optimization. Instead, it never hits it. Today, glamor_get_vbo_space() binds the VBO, and glamor_put_vbo_space() explicitly unbinds it. This means that our VBO is never bound on a get operation, so we pay the hash table cost every time we call glamor_get_vbo_space(). Every get/put also alter reference counts, so we pay that cost twice over. This patch removes the explicit unbind, which makes us hit the fast path on every get/put (except the rare ones which create a new buffer). When running a fullscreen GL application under xf86-video-modesetting (which doesn't do page flipping yet), glamor_get_vbo_space() accounted for 4.24% of the CPU instructions in each glamor_copy_fbo_fbo_draw() operation. With this patch, it became only 0.87%. Signed-off-by: Kenneth Graunke <[email protected]> Cc: Eric Anholt <[email protected]> --- glamor/glamor_vbo.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c index e906101..5d7c55f 100644 --- a/glamor/glamor_vbo.c +++ b/glamor/glamor_vbo.c @@ -150,8 +150,6 @@ glamor_put_vbo_space(ScreenPtr screen) glBufferData(GL_ARRAY_BUFFER, glamor_priv->vbo_offset, glamor_priv->vb, GL_DYNAMIC_DRAW); } - - glBindBuffer(GL_ARRAY_BUFFER, 0); } void -- 2.2.1 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
