[Mesa-dev] [Mesa3d-dev] [RFC] Draw module optimizations

[Jakob Bornecrantz]

On Mon, Jan 24, 2011 at 5:02 PM, Brian Paul <brianp at vmware.com> wrote:
> On 01/23/2011 10:30 PM, Jakob Bornecrantz wrote:
>>
>> Hi all
>>
>> I have pushed some draw module changes here
>> http://cgit.freedesktop.org/~wallbraker/mesa/log/?h=i915g-speed&showmsg=1
>> which improves speed in the draw module by avoiding unneeded flushing
>> and setup on draw calls.
>>
>> The first two commits (starting from the bottom, right after master)
>> doesn't yield much improvements especially after the last commit.
>>
>> Remove_reduce_prim is required as any call to draw_do_flush would
>> result in the following call draw_vbo would be called with
>> STATE_CHANGE, which with the last commit would call into prepare when
>> it is not needed.
>>
>> The last commit is the one that does the biggest difference. As it is
>> the one that stops prepare from being called on every draw_vbo call.
>> And as a side effect removes the last draw_do_flush call, enabling at
>> last the pipeline to gather up vertices from several draw_vbo calls
>> into a single draw_elements. The paste below shows the difference,
>> first column are from the test application (tests/step that I just
>> pushed), the rest are either from i915g or draw, it should be obvious
>> which is which.
>>
>> http://pastebin.com/5i3BejgJ
>>
>> A follow up to these changes would be try to unify draw_pipe_vbuf and
>> draw_pt_emit into a single file or to refractor code into a single
>> vbuf primitive collector that would allow draw_arrays calls to be
>> grouped into a single vbuf_render->draw_arrays call (provided
>> primitive can be combined). This would improve draw_pt_emit_run_linear
>> performance on draw heavy applications. I guess one could also look
>> into merging draw_elements with each other by manipulating indices
>> (between draw_pt_emit and the pipeline). As well as draw_arrays and
>> draw_elements by doing the same.
>>
>> Comments please.
>
> Jakob,
>
> I pulled your branch and tested with piglit with llvmpipe.  Looks like
> there's a number of regressions in the "general" catagory:
>
> general/bgra-sec-color-pointer
> general/bgra-vert-attrib-pointer
> general/draw-batch
> general/draw-elements
> general/draw-vertices
> general/primitive-restart
> etc.
>
> You can run this group of tests with:
>
> ./piglit-run.py -t ^general tests/all.tests results/new
>
> I suspect that either the reduced prim removal or one of the new
> conditionals put around the flushing code is at fault.
>
> Otherwise, this patch series looks like good stuff.

Thanks for testing.

I fixed the regressions for softpipe and llvmpipe and pushed the
changes to http://cgit.freedesktop.org/~wallbraker/mesa/log/?h=draw-optz&showmsg=1
. It does regress some wine games on i915. So I will hold of with
pushing it until that is solved. Also sorry for changing branch name
it was slightly more fitting.

As I mention in the two commits that fix the sw-pipe regressions we
can problably redo the draw module flushing to be a flag instead where
you select which part of the draw pipeline you want to flush (or
revalidate). FLUSH_FRONTEND, FLUSH_FETCH, FLUSH_BACKEND and
STATE_CHANGE would be = frontend | fetch | backend.

Comments please?

Cheers Jakob.