[Mesa-dev] [PATCH 0/6] Mesa/Gallium vertex array state optimizations

José Fonseca jfonseca at vmware.com
Mon Feb 14 10:02:28 PST 2011


Apart of some subtleties with removing pipe_vertex_buffer::max_index, I
think this looks great.

I'm OK with addressing the pipe_vertex_buffer::max_index issues after
commiting this series, as well behaved applications should not be


On Sat, 2011-02-12 at 11:05 -0800, Marek Olšák wrote:
> Hi,
> this patch series optimizes vertex array state changes in Mesa/Gallium. The problem with the vbo module and st/mesa is that it re-binds vertex arrays every draw operation instead of only when they get changed by the application, and this series aims to address that issue.
> Some new issues arose during the implemention though:
> 1) The VBO module didn't notify the underlying driver when it was
> changing buffer offsets and other vertex array properties. This is
> fixed in the 1st patch.
> 2) If we do not re-bind vertex arrays every draw operation, we must assure that the state is preserved after operations like glBlitFramebuffer. This is resolved in the 3rd patch using cso_cache.
> 3) Unfortunately, user buffers must be mutable in order to prevent re-binding vertex buffers because we have no way to know how large they are. Instead, a new context hook has been added to Gallium called 'redefine_user_buffer', which notifies a driver that a subrange of a user buffer should be reuploaded, and also redefines its size.
> I've only tested softpipe and r300g and there were no regressions. r600g should also work and Christopher told me his Nouveau drivers should be ready for this series too.
> Please review.
> Marek Olšák (6):
>       vbo: notify a driver that we change buffer offsets, strides, etc.
>       vbo: bind arrays only when necessary
>       gallium: always save and restore vertex buffers using cso_cache
>       gallium: remove pipe_vertex_buffer::max_index
>       st/mesa: set vertex arrays state only when necessary
>       gallium: notify drivers about possible changes in user buffer contents
> Best regards
> Marek

More information about the mesa-dev mailing list