[Mesa-dev] [PATCH] Unified st_context::draw_vbo
Keith Whitwell
keithw at vmware.com
Sun Jul 18 04:31:04 PDT 2010
On Fri, 2010-07-16 at 11:10 -0700, Chia-I Wu wrote:
> Hi all,
>
> This patch series replaces
>
> st_context::draw_arrays
> st_context::draw_elements,
> st_context::draw_arrays_instanced
> st_context::draw_elements_instanced
> st_context::draw_range_elements
>
> by a single
>
> st_context::draw_vbo(struct pipe_context *pipe,
> const struct pipe_draw_info *info);
>
> The series is too big in size and I have to push it to
>
> http://cgit.freedesktop.org/~olv/mesa/log/?h=gallium-unified-draw
>
> Since the drivers no longer need to implement all the drawing
> variants, the diffstat says
>
> 29 files changed, 359 insertions(+), 1061 deletions(-)
>
> Its main user (st_draw_vbo) is also simplified.
>
> There are 4 commits in the branch. The first commit adds the new
> function prototype to the header file. The second commit implements
> draw_vbo for all pipe drivers. The third commit converts all state
> trackers (st/mesa, st/vega, and util_draw_vertex_buffer) to use
> draw_vbo. The last commit removes all other variants from the
> interface.
>
> This looks like a nice cleanup to have to me. Suggestion?
If we're reorganising these interfaces, there are a couple of things I'd
like to see done differently. In particular, within your draw_info
struct there are a couple of entities which are often better handled as
persistent state - namely the primitive mode and index buffer binding.
Right now we've got a single call which sets as much state as
glMultiDrawElementsIndexed, but which can only draw a single primitive.
The ways out of this situation are to either move state out of
per-primitive transaction, or to modify the interface to accept >1
primitive at a time.
My preference would be to move primitive mode & index buffer (and other
stuff too?) out of your info struct and turn them into new dynamic state
calls.
Having done that, it may still be worth considering passing >1 of your
info structs to the new unified entrypoints...
Keith
More information about the mesa-dev
mailing list