[Mesa-dev] draw: Replace varray and vcache by vsplit

[Keith Whitwell]

On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
> Hi,
> 
> There are two primitive transformations in gallium draw module.  In
> varray, primitives are "split"ted.  When a primitive has more vertices
> than the middle end can handle, varray splits the primitive and calls
> the middle end multiple times.
> 
> In vcache, primitives are "decompose"d.  More advanced primitives are
> decomposed into one of point, line(_adj), or triangle(_adj).
> Similarly, vcache may call the middle end multiple times to flush its
> internal buffer.  In some cases, vcache passes the primitves through
> without decomposing nor splitting, as can be seen in vcache_check_run.
> 
> The issue with vcache is that it has to decompose a primitive
> differently depending on the provoking convention, as explained in
> 
>   http://lists.freedesktop.org/archives/mesa-dev/2010-August/001797.html
> 
> It becomes a problem when GS is active.
> 
> My proposal is to make vcache split instead of decompose.  Because
> varray only splits and vcache has a pass-through path, the rest of the
> workflow already has to support all primitive types.  Switching from
> decompose to split does not require a big change to the rest of the
> workflow.
> 
> But then vcache will look a lot like varray, only with indexed
> primitive support.  It leads me to a new frontend that replaces both
> varray and vcache: vsplit
> 
>  http://cgit.freedesktop.org/~olv/mesa/log/?h=draw-vsplit
> 
> vsplit is based on varray.  It uses some code from vcache to support
> indexed primitives.  When vcache decomposes, there are flags being set
> to indicate that if the stipple counter should be reset or if some
> edge of a triangle should be omitted in unfilled mode.  The segments
> of a splitted primitive have flags for similar purposes too:
> 
>   DRAW_SPLIT_AFTER   More segments to come after this one
>   DRAW_SPLIT_BEFORE  There are preceding segments
> 
> These flags are set by vsplit and the middle ends pass them to the
> other stages.  Therefore, the run methods of middle ends are augmented
> to take the flags.
> 
> To summarize, vsplit
> 
>  - fixes GS when (flatshade && flatshade_first) is on
>  - never sends more vertices than the middle end claims to handle
>  - is faster than vcache: split instead of decompose, no get_elt
>    calls
>  - no longer uses the higher bits of draw_elts for stipple/edge flags
> 
> Suggestions?


Hi - I haven't looked at the patches yet, but a couple of questions:

How does this interact with the draw_pipe_* code - which requires
decomposed primitives?

How does this cope with indexed rendering where the vertex buffers
themselves are too large (for hardware or some other entity)?  Eg.
imagine the hardware could cope with up to 64k vertices, and you have a
drawelements call randomly referencing vertices in range 0..128k ?

Keith